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(57) 



ABSTRACT 



In accordance with the invention, a method is provided for 
remotely managing a plurality of network element of a 
telecommunications network through a special communica- 
tion link including a computer internet such as a local area 
network, the world wide web or the Internet. A management 
computer is connected to ao element management system 
server through a communication link including the computer 
internet. At least one of the plurality of network elements is 
also coupled to the element management server through the 
computer internet and the at least one of the plurality of 
network elements is managed via communications conveyed 
through the element management server between the man- 
agement computer and the at least one network element. 

28 Claims, 23 Drawing Sheets 
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TERM 



DEFINITION 



MANAGED 
OBJECT 



AN ABSTRACT REPRESENTATION OF A RESOURCE THAT MAY BE 
MANAGED BY THE NETWORK MANAGEMENT PLATFORM. 
EXAMPLES INCLUE A NETWORK ELEMENT, A MAINTENANCE 
UNIT, NETWORK ELEMENT SUMMARY, DATALINK. 



CLIENT A FUNCTION PASSED BY THE CLIENT TO THE SERVER THAT IS 

CALLBACK USED BY THE SERVER TO DELIVER ASYNCHRONOUS 
FUNCTION NOTIFICATIONS OF ATTRIBUTE CHANGES, CONFIGURATION 
CHANGES OR EVENT NOTIFICATIONS. 



CALLBACK 

OBJECT 

REFERENCE 



A REFERENCE IN THE EMS SSERVER TO THE CALLBACK OBJECT 
WITHIN THE CLIENT. THE REFERENCE IS USED BY THE SERVER 
TO INVOKE THE METHOD WITHIN THE CALLBACK OBJECT TO 
DELIVER A NOTIFICATION. 

MANAGED A NAMED SET OF MANAGED OBJECTS THAT SHARE THE SAME 
OBJECT SETS OF ATTRIBUTES, NOTIFICATIONS AND MANAGEMENT 

CLASS OPERATIONS. AN EXAMPLE IS T HE AP MANAGED OBJECT CLASS. 



MANAGED 
OBJECT 
CLASS 
CODE 



A CODE THAT IDENTIFIES A SPECIFIC MANAGED OBJECT CLASS 
(UNIQUE TO THE SYSTEM). THIS CODE IS A CONSTANT 
(ENUMERATION OR INTEGER DEFINITION. 



INSTANCE AN INTEGER VALUE THAT IDENTIFIES A SPECIFIC INSTANCE OF 
IDENTIFIER A MANAGED OBJECT AND IS UNIQUE WITHIN ITS MANAGED 

OBJECT CLASS. 

MANAGED THE COMBINATION OF MANAGED OBJECT CLASS CODE AND 
OBJECT INSTANCE IDENTIFIER DEFINES THE MANAGED OBJECT 
IDENTIFIER IDENTIFIER, ALSO ABBREVIATED AS AN MOID. 

SERVICE THE OBJECT THAT PROVIDES SERVICES FOR A MANAGED 
OBJECT OBJECT CLASS. CLIENT APPLICATIONS ACQUIRE A REFERENCE 
TO THIS OBJECT (IN CORBA THEY BIND TO THE OBJECT). AN 
EXAMPLE IS THE AP SERVICE OBJECT AND THE USER SESSION 
SERVICE OBJECT. 



ATTRIBUTE A PROPERTY OF A MANAGED OBJECT. 

A VALUE. 



AN ATTRIBUTE HAS 



ATTRIBUTE A CODE THAT IDENTIFIES A SPECIFIC ATTRIBUTE OF A 

CODE MANAGED OBJECT CLASS. 

METHOD OR AN OPERATION OR METHOD ON A MANAGED OBJECT 
OPERATION PERFORMS AN ACTION. 



NOTIFICATION 



INFORMATION EMITTED BY A MANAGED OBJECT RELATING TO 
AN EVENT THAT HAS OCCURRED WITHIN THE MANAGED OBJECT. 
AN EXAMPLE IS AN ATTRIBUTE CHANGE NOTIFICATION. 



INHERITANCE THE CONCEPTUAL MECHANISM BY WHICH ATTRIBUTES, 

NOTIFICATIONS, OPERATIONS, AND BEHAVIOR ARE ACQUIRED BY 
A SUBCLASS FROM ITS SUPERCLASS. __ 



USER EACH CLIENT MUST ESTABLISH A UNIQUE SESSION THAT IS 
SESSION USED TO VALIDATE ACCESS PERMISSIONS AND FOR 
SUBSEQUENT ROUTING OF NOTIFICATIONS. 

MARSHALING ENCODING AND DECODING AN OPERATION AND ITS 
PARAMETERS INTO FLATTENED MESSAGE FORMATS. 

CONTAINMENT A STRUCTURING RELATIONSHIP FOR MANAGED OBJECT 

INSTANCES IN WHICH THE EXISTENCE OF A MANAGED OBJECT 
INSTANCE IS DEPENDENT ON THE EXISTENCE OF A CONTAINING 
MANAGED OBJECT INSTANCE. AN EXAMPLE IS THE RCS OBJECT 
CONTAINED WITHIN THE AP OBJECT. 



FIG. 6 
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TABLE 1 - EMAPI SERVER INTERFACE 


IN ITS CURRENT FORM. THE PRIMARY FUNCTION OF THE USER SESSION MANAGER IS TO 
MAINTAIN A LIST OF ACTIVE CLIENT SESSIONS AND APPLICATIONS. IN SUBSEQUENT RELEASES, 
THIS SERVICE OBJECT WILL PROVIDE USER ACCESS SECURITY ON A NETWORK-ELEMENT AND 
OPERATION BASIS. REFER TO THE SECTION ON SESSION MANAGEMENT FOR A DISCUSSION OF 
THE INTERFACES PROVIDED BY UserSesslon. 


FOR EACH PHYSICAL OR LOGICAL RESOURCE WHICH MUST BE MANAGED BY THE EMS. AN 
ABSTRACT REPRESENTATION WILL BE DEFINED WHICH IDENTIFIES ATTRIBUTES AND 
OPERATIONS ASSOCIATED WITH THE RESOURCE. EACH APPLICATION-SPECIFIC MANAGED 
OBJECT IMPLEMENTED ON THE SERVER MUST PROVIDE THE SAME CLIENT INTERFACES FOR 
RETRIEVING CONFIGURATION INFORMATION. ATTRIBUTE VALUES. AND REGISTRATION FOR 
NOTIFICATION OF CHANGES. REFER TO THE SECTION ON MANAGED OBJECTS FOR FURTHER 
DETAILS. 


EACH APPLICATION-SPECIFIC NEMO IMPLEMENTED ON THE SERVER MUST PROVIDE 
ADDITIONAL INTERFACES ABOVE THOSE PROVIDED BY THE STANDARD MANAGED OBJECT TO 
SUPPORT NETWORK-ELEMENT LEVEL CONFIGURATION QUERIES. REFER TO THE SECTION ON 
NETWORK ELEMENT LEVEL MANAGED OBJECTS FOR FURTHER DETAILS. 


THE EVENT DISTRIBUTOR PROPAGATES EVENTS EITHER RECEIVED OR GENERATED AT THE 
SERVER TO CLIENTS WHICH REGISTER FILTERS SPECIFYING EVENT FILTER CRITERIA. REFER 
TO THE SECTION ON THE EVENT DISTRIBUTOR FOR THE DEFINITION OF AN EVENT AND EVENT 
FILTER, AND A DISCUSSION OF THE CLIENT INTERFACES PROVIDED BY EvtDlst. 


THE AlarmManager IMPLEMENTS INTERFACES FOR A SINGLE CLIENT APPLCIATION CALLED THE 
AlarmList. (NOTE THAT THERE MAY BE MORE THAN ONE INSTANCE OF THE AlarmUst 
APPLICATION ACTIVE AT ANY ONE TIME). ALARM FILTERS MAY BE REGISTERED WHICH FILTER 
ALARM INFORMATION BASED ON NETWORK ELEMENT, MANAGED OBJECT OR ALARM LEVEL. 
THE AlarmManager RETURNS AN INITIAL VIEW OF ALL ACTIVE ALARMS MATCHING THE 
SPECIFIED CRITERIA, AND PROVIDES NOTIFICATION OF CHANGES RESULTING FROM 
SUBSEQUENT ALARM SET OR CLEAR EVENTS. REFER TO THE SECTION ON THE ALARM 
MANAGER FOR THE DEFINITION OF AN ALARM AND ALARM FILTER, AND A DETAILED 
DISCUSSION OF THE CLIENT INTERFACES PROVIDED BY THE AlarmManager. 




USER SESSIONS 
MANAGER 
(UserSession) 


MANAGED OBJECT 
(MO) 


NETWORK- 
ELEMENT 
LEVEL MANAGED 
OBJECT (NEMO) 


EVENT 
DISTRIBUTOR 
(EvtDlst) 


ALARM 
MANAGER 
(AlarmManager) 



(0 

0 
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METHOD FOR COMPUTER INTERNET 
REMOTE MANAGEMENT OF A 
TELECOMMUNICATION NETWORK 
ELEMENT 

BACKGROUND OF THE INVENTION 
This invention generally relates to a telecommunication 
network and more particularly to managing network ele- 
ments of the telecommunications network. 

Network management systems in which a management 
computer, or work station, runs a management computer 
program, or management application, to manage a set of 
management agent computer programs, or management 
agents, associated with a corresponding set of network 
elements are known. Such known management systems 
employ a communication protocol that employs a manage- 
ment information base for each network that defines the 
interface between the management application and the net- 
work element. These management systems are implemented 
only at the individual network elements and have not been 
successfully employed for large scale management of a 
telecommunications network. 

SUMMARY OF THE INVENTION 
In accordance with the invention, a method is provided for 
remotely managing a network element of a telecommunica- 
tions network through a special communication link includ- 
ing a computer internet. A management computer is con- 
nected to an element management system server through a 
communication link including a computer internet. At least 
one of the plurality of network elements is also coupled to 
the element management server through the computer inter- 
net and the at least one of the plurality of network elements 
is managed via communications conveyed through the ele- 
ment management server between the management com- 
puter and the at least one network element. 

Preferably, management is facilitated by the management 
server generating an interactive web page at a client work- 
station with objects associated with management of the at 
least one network element. The interactive web page is 
transmitting from the management server through the com- 
puter internet to the management computer and displayed at 
the interactive web page at the management computer for 
management communications between the management 
computer and the network element. Objects of the interac- 
tive web page include objects associated with preferably all 
three of operation, administration and maintenance of the 
network element. 

In an embodiment, the interactive web page includes a 
detailed status summary page for each network element of 
the telecommunications network, a relatively high system 
status summary of all the plurality of network elements and 
a list of all active alarms within the telecommunications 
network. 

The plurality of network elements each have an associated 
applications processor with a management agent application 
for interfacing the element management server with the 
network element. The application processor includes a 
maintenance application for performing maintenance of the 
network element command request are interfaced from the 
element management server through the management agent 
application to the maintenance application to selectively 
perform maintenance tasks. The element management server 
is provided with application processor specific events and 
command acknowledgments. 

Preferably, the computer internet is the world wide web, 
or Internet, connections and communications are achieved 
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through operating world wide web based JAVA applications 
at the management computer and the element management 
server. Alternatively, the computer internet is a local area 
network. In this way, multiple management computers at 

5 different remote locations are capable of accessing any and 
all of the network elements of the telecommunications 
network. Multiple commands simultaneously received from 
a plurality of different management computers are queued 
and the multiple commands are responded to by sending 

10 responses to only the appropriate ones of the different 
management computers that originated the corresponding 
commands. Connection of the management computers to the 
special element management server is preferably enabled 
only in response to entry of a correct password at the 

is management computer. Preferably, the password is 
encrypted prior to being sent to the element management 
server. 

Thus, the invention also includes the concept of managing 
all of the plurality of network elements from a plurality of 

20 different remote management computers by performing the 
steps of selectively running a management application at a 
plurality of different work station for command, control and 
fault management of the network elements, interfacing an 
element management server through a computer internet to 

25 the plurality of different work stations to provide distributed 
network element management services to the management 
application at all of the plurality of work stations, and 
interfacing the network element with the element manage- 
ment server through a management agent application asso- 

30 ciated with the network element for communicating com- 
mand acknowledgment and command requests through the 
computer internet between the network management server 
and the network element. 
Thus, a method is provided which overcomes the defi- 

35 ciencies of known network element management systems 
and methods that provides distributed network management 
for enhanced efficiency and convenience which has the 
features needed for large scale management of a telecom- 
munications system. 

40 Appendix A provides a definition of terms and a glossary 
of acronyms included in this application. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The forgoing advantageous features will be made appar- 
45 ent and other features of the invention will be described in 
the detailed description of the preferred embodiment that is 
given with reference to the several figures of the drawing, in 
which: 

5Q FIG. 1A is a functional block diagram of an embodiment 
of the network element management system in which the 
management computer, or work station, is employed to 
control, or manage, a plurality of network elements of a 
telecommunication network through a public switched tele- 

55 phone network (PSTN); 

FIG. IB is a functional block diagram of an embodiment 
of the network element management system in which the 
management computer, a work station, is employed to 
control, or manage, a plurality of network elements of a 

60 telecommunications network through a computer internet; 
FIG. 1C is a functional block diagram of an embodiment 
of the network element management system in which the 
management computer, or work station, is employed to 
control, or manage, a plurality of network elements of a 

65 telecommunication network through a local area network; 
FIG. 2 is a functional block diagram of an element 
management system in which the management of a network 
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element is accomplished at a web enabled workstation with 
off-the-shelf components and proprietary applications; 

FIG. 3 is a functional block diagram of the major software 
of the architecture of the invention; 

FIG. 4 is a functional block diagram for the element 
management system server and a client workstation with an 
associated network element and its associated simple man- 
agement protocol (SNMP) agent. 

FIG. 5 is a functional block diagram showing element 
management system client configuration; 

FIG. 6 is a table of terms associated with the managed 
object model in accordance with the invention; 

FIG. 7 is a functional block diagram showing the deriva- 
tion of application process 

FIG. 8 is a functional block diagram of managed object 
classes and their containment relationship that may be used 
to manage to application process; 

FIG. 9 is a block diagram showing a network element, AP, 
service object and the data it contains and an ECP managed 
object using a protocol other than SNMP for communica- 
tion; 

FIGS. 10, 11, 12 and 13 show representative web pages in 
accordance with the invention; 

FIG. 14 is a functional block diagram of a network 
element, AP, software architecture; 

FIG. 15 shows element manager client application pro- 
gramming interfaces; 

FIG. 16 shows the service objects resident on the server 
with which client applications interact; 

FIG. 17 shows the callback interfaces defined in the 
EMAPI; 

FIG. 18 shows data types defined in the EMAPI; 

FIG. 19 shows the relationship between client, 
application, specific service object, and the internal server 
representation of managed object instances; 

FIG. 20 shows filter criteria which are valid for each event 
category; and 

FIG. 21 shows an EMAPI specific exception defined with 
an EMAPI exception code containing one of a plurality of 
values. 

DETAILED DESCRIPTION 

FIG. 1A illustrates a system 10 in which the method of 
managing a network element 14 at a web enabled worksta- 
tion 16 is shown. A management computer 26 associated 
with an element management system client 28 is connected 
to a network element 14 and element management system 
client 32 through a public switched telephone network 
(PSTN) 33. 

FIG. IB illustrates a system 34 in which the method of 
managing the network element 14 in a telephonic network at 
web enabled workstation 16 is shown. Network element 14 
is connected through a telephonic computer network 35 to a 
computer internet 36. The management computer 26 asso- 
ciated with the element management system client 28 is 
connected to the element system management system sever 
32 over a telephonic system network 34 through the com- 
puter internet 35 and a telephonic link 38. 

FIG. 1C illustrates a system 40 in which the managing of 
the network element 14 is performed from the management 
computer 26 with the associated element management sys- 
tem client 28 with the element management system 32 via a 
local area network 42. 
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The method in accordance with a the invention enables 
the leveraging of off-the-shelf technology to enable addi- 
tional client visible features, while extending to subsequent 
releases and other projects, with little to no increase to cost 
5 of goods. 

Referring to FIG. 2, the network element 14 is provided 
through the element management system client 28 and a 
SNMP-based element management platform. The method in 
accordance with the invention works with off-the-shelf 
components 44, 45, 46, 47, 48 and 49 and propriety appli- 
cations 50, 52, 54, 55 and 56. The off-the-shelf technologies 
include: the HTML and Java apps 44, the web browser 45, 
the web server 46, Transport Protocols [TCP/IP UDP/IP] 47, 
CORBA 48, and the SNMP element management platform 
(HP Open View Network Node Manager [HPOVNNM]) 49, 
15 alternatively a Carnegie-Mellon University (CMU) SNMP 
library is used, and the Transport Protocols (TCP/IP protocol 
suite). 

The client executes the Client Interface and propriety 
applications via Web pages. Microsoft Internet Explorer and 

20 netscape browsers are supported as are the web-enabling 
devices for PCs and X-terminals. Through a Web-based 
graphical client interface, clients' commands generate 
HTTP requests to the element management system server. 
The server gathers information, dynamically generates a 

25 Web page, and sends the results/output to the web browser 
for display. 

Client applications (JAVA Applets) include proprietary 
applications such as, an active alarm list browser, a system 
alarm summary, and a network element detailed status 

30 display. Gient applications communicate with the server via 
an object oriented interface to the element manager API 
(EMAPI) 55 through the distributed object request architec- 
ture (CORBA) 48. This interface provides a consistent 
interface to all managed objects in the network, and hides 

35 the implementation details associated with the element man- 
ager platform. 

The element management system server 32 executes 
applications to serve information to clients via CORBA 
middleware. CORBA will serve as the IPC for functions 

40 residing on the server, thereby eliminating any platform- 
specific IPC from the implementation, and providing for 
distribution of functionality to multiple processors if needed 
in the future for performance. Communication between the 
element management system and the managed elements is 

4 5 via SNMP. System status is obtained through SNMP polling 
and audits, SNMP traps are used for real-time notifications, 
and SNMP sets are used for command and control. The 
element management system has no persistent store over a 
system boot, and requires a handshake with each network 

50 element when the element management system is initialized; 
however, it does store information for use by multiple 
clients, so it does not need to get this information for each 
request from a new client. Command and alarm output is 
displayed via the Web browser based display, as well as sent 

55 to an executive control processor read only printer. 

The network element 14 is responsible for processing 
event and alarm notifications to the element management 
system via SNMP, and for issuing commands for obtaining 
information from applications. A management information 

60 base (MIB) 56 conventions is defined for managing network 
elements in the system. The MIB 56 conventions define 
command execution, message sequencing, and audit 
provisions, that are used within the element management 
system architecture but are not provided for in SNMP. 

65 The following is a description of the functional block 
diagram shown in FIG. 3 of the software components of the 
invention. 
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Element Management Server Software Components 

The element management system client 28 is the clients 
interface to the element management system server 32. It 
consists of the web browser 45 and the JAVA applets 44. 

Web Browser: The web browser 45 is the interface to end 
client, a host for JAVA applets 44, and a virtual machine 
for JAVA execution. Netscape and MS Explorer are 
both supported (for platforms that support these 
browsers). 10 

JAVA Applets: JAVA Applets 44 include but are not 
limited to the following: 

System Summary Application: provides a hierarchical 
view of alarm status, summary icons for parent 
nodes, color encoding of alarm states, and point/click 15 
navigation to Network Element Detailed Status 
screens; 

Network Element Detailed Status Application: pro- 
vides a custom view of each network element, dis- 
plays static configuration data, and maintenance state 20 
of all managed objects; 
Active Alarm List Browser Application: displays the 
current list of outstanding alarms in the system. 
The major software components of the Element manage- 
ment system server include: 25 
HTTP Web Server 58: processes HTTP requests from the 
element management system Client that retrieve and 
download HTML pages and Java applets (from the 
element management system Server hard disk) associ- 
ated with the element management system Client appli- 30 
cation (from the element management system Server 
hard disk). 

Orbixd 60: Iona Orbix daemon, the object request broker 
Orbix Naming Service 64: an Orbix process that services 

object locator requests 35 
Object Server 66: a single UNIX process that provides 
most of the element management system server func- 
tionality. It is described in detail in later sections of this 
document. 

40 

Active Alarm Manager 68: provides for client access to 
alarms currently active in the system and represents the 
element management system component of the Client 
Alarm List application. 

HPOV processes 70: provide the network management 45 
system infrastructure (SNMP API, trapd, postmaster 
daemon). Alternatively, the network management sys- 
tem is performed by a CMU SNMP library. 

ROP Formatter 72: translates binary message codes into 
ASCII text in accordance to ECP ROP formatting 50 
practices. It then directs the formatted ASCII output to 
the ROP stream. 

Command Line Interpreter 76: provides an ASCII com- 
mand language interface to allow the technician to 
enter commands at the element management system 55 
and observe results. 

UX Proxy 78: UX message interface (bridge between 
System V message queues and sockets) to an internal 
database subsystem (IDS) 79. 

INTERNAL DATABASE SUBSYSTEM (IDS) 79: ECP 60 
Ring Database Update triggers the object server 
(through UX Proxy) when an AP is added to the system. 

Application Processor (AP) Components 
The following components reside on the AP 80: 65 
SNMP Agent 81: sends and receives messages between 
the AP and element management system infrastructure. 
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It is also responsible for the throttling traps to prevent 
overloading the system. 

the internal database subsystem (IDS) 79: ECP Ring 
Database Update downloads AP configuration data and 
updates from a ECP 82. 

ECP Agent 86: processes IDS triggers, notifies AP appli- 
cations of changes to their configuration data, and send 
configuration changes (events) to the event handler. 

Command Handler 88: Handles AP administration com- 
mand requests issued from either the GUI based or text 
based client interfaces. Executes a RAP 90 to complete 
the administration request. Returns the completion 
information back to the element management system 
server. Keeps list of active commands in AP Command 
Table. 

Text Command Interpreter 92: A text based interface for 
special situations in which the GUI based interface 
presented by the element management system Server is 
not available to the client. 

Event Handler 94: The Event Handler is responsible for 
handling both the filtering and forwarding of events 
(alarms, notifications, state changes, configuration 
changes) to the element management system. Updates 
the State and Alarm Tables in NEST. 

NE Status Table 96: also known as the NEST, stores 
maintenance object state and alarm information, as well 
as the list of active commands. 

RAPs 90: The Resource Administration Process is an 
application processing interface(API) for fork-exec*ing 
a process and obtaining the results of the process 
execution 

Other platform and application software 98: encompasses 
all the entities involved in command execution that 
aren't otherwise displayed on the diagram due to the 
desire not to get into too much detail. This includes the 
RCC resource monitors and resource daemons that 
come into play when executing an RCC 100 based 
element management system command (e.g., remove 
DS1 digital switch), as well as the software application 
specific to a given resource (e.g., RCS, MMA, CCM, 
SS7). 

RCC 100: as shown it is the call to RCC 100 APIs to 
generate RCC events for taking a resource out of 
service. This bubble only comes into play when RCC- 
based element management system commands are 
executed. Since this is only an overview, the case for 
non-RCC-based element management system com- 
mands (e.g., diagnose DS1) is not shown. 

AP State Monitor 104: a bridge mapping RCC 100 events 
into locally understood AP 80 events. 

REFERENCES 

The following describes the architecture of the element 
management system server and the distributed client appli- 
cations. 

The following provides reference material that may be 
useful as background information, the disclosures of which 
are incorporated by reference. 
Object Oriented Technology 
Taylor, David A "Object Oriented Technology: A Man- 
agers Guide". Addison-Wesley, 1993. ISBN 0-201- 
56358-4. 

Booch, Grady. "Object Oriented Analysis and Design 
with Applications". Benjamin/Cummings. 1994. ISBN 
0-8053-5340-2 
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Network Management 

Stallings, William. "SNMP, SNMPv2, and CMIP. The 

Practical Guide to Network-Management Standards". 

Addison-Wesley, 1993. ISBN 0-201-63331-0. 
Rose, Marshall T. "The Simple Book — An Introduction 

To Internet Management" Prentice -Ha 11. 1994. ISBN 

0-13-177254-6. 
"Hewlett-Packard Open View Network Node Manager 4.1 

Technical Evaluation Guide", Hewlett Packard Corpo- 
ration. April 1996. 
"HP OpenView Using Network Node Manage", Hewlett 

Packard Corporation. April 1996. 
Carnegie-Mellon SNMP libraries; http:// 

www.net.cmu.edu/projects/SNMP. 
Web Technology 
The World Wide Web Consortium Web Site <http:// 

www.w3.org/> Contains references, white papers and 

RFCs relating to web technology. 
CORBA 

Orfali, Robert et. al. "The Essential Distributed Objects 
Survival Guide". John Wiley and Sons. 1996. ISBN 
0471-12993-3. 

Vinoski, Steve, "Distributed Object Computing With 
CORBA". Hewlett-Packard Company, 1993. (Article 
published in the July/August 1993 issue of C++ Report 
magazine. 

The Object Management Group Web Site <http:// 
www.omg.org/>. Contains standards documents, white 
papers and links to information on CORBA 
FIG. 4 shows a summary of the principle functional 
components on the element management system server and 
a single client workstation. A single managed network 
element 14 is shown with its associated SNMP Agent. A 
table in FIG. 4 provides a definition of terms used in the 
subsequent description. 

Element Management System Client Components 

Element management system client 28 components con- 
sist of web browser hosted applications that provide network 
element command and control and fault management. These 
web browser hosted applications provide a graphical client 
interface based client interface in a cross platform environ- 
ment. The server infrastructure supports applications for 
performance and security management. 

The client interface to the server is described in the 
EMAPI 55 described in a pending patent application previ- 
ously incorporated by reference herein. The EMAPI 55 is 
implemented utilizing an industry standard object manage- 
ment group interface description language (IDL). The inter- 
faces and semantics of the EMAPI 55 enable client appli- 
cation processes to utilize this interface to provide 
management of the system. Distribution of this interface is 
achieved through use of the Common Object Request Bro- 
ker Architecture (CORBA) which provides a distributed 
object request architecture. 

Client applications utilize the EMAPI 55 to access service 
objects on the server which provide access to attributes of 
the managed objects, provide maintenance operations for 
those managed objects, and allow the client to register for 
notifications of attribute changes and event notifications 
(which typically will be command acknowledgments and 
command results). 

The development of client applications depends only on 
the EMAPI 55 interface specification. The use of CORBA 
allows the clients to be distributed and implemented in a 
different language (such as Java) than the server (in C++). 
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The element management system server 32 consists of a 
set of software components that provide an SNMP network 
management framework and distributed network manage- 
ment services to client applications. The method in accor- 
5 dance with the invention uses off-the-shelf software com- 
ponents. The off-the-shelf software components included in 
the element management system are: 

(a) HTTP Web Server 

(b) Netscape or Microsoft® Internet Explorer Web 
10 Browser 

(c) Orbix Daemon 

(d) Orbix Naming Service 

(e) HP OpenView Network Node Manager (HPOVNNM) 
15 or alternatively, a CMU SNMP library package 

The element management system server 32 software 
components that are provided by the applicant include: 

(a) object server 66 

(b) active alarm manager 120 

(c) unix subsystem proxy 

(d) read only printer formatter 

(e) command line interpreter 

The first two components, the object server 66 and the 
25 active alarm manager 120, provide the bulk of the server 
functionality required to support the element management 
system client applications. The other three components 
serve important supporting roles. 

Off the Shelf Element Management System Server Compo- 
30 nents 

HTTP Web Server (Generally called Web Server) 
This off the shelf functionality serves static and dynamic 

web pages to client browsers. The web server must provide 

support for HTTP 1.0 (or greater), CGI scripts and provide 
35 a built in API for the creation of dynamic web pages "on the 

fly*'. The Web server supports the following: 
CGI script execution. 

Automatic startup from init (no human intervention to 
start server) 

40 logging of page access. A log file containing the IP 
address and the URL referenced. This is used to exam- 
ine access patterns and detect and trace access from 
unauthorized sources. 
45 Web page access control based on client name and pass- 
word. The server supports basic server authentication, 
and can be enhanced to support SSL (Secure Socket 
Layer) if encryption of the browser to server connec- 
tion is required. 
50 Secure administrator administration of web server includ- 
ing administration of the client name and password for 
access control. 
Orbix Web Server 

Part of the Orbix product. Required to support CORBA 
55 within a Web browser. Enables JAVA applets downloaded to 
the client to communicate via CORBA to the element 
management system Server. 
Orbix Daemon (CORBA ORB) 

The CORBA ORB represents the server side of CORBA 
60 and is provided by an off-the-shelf CORBA implementation . 
The Common Object Request Broker Architecture 
(CORBA) is utilized in this architecture to provide inter- 
process and inter-processor communication between clients 
using the EMAPI 55. 
65 CORBA is a platform-independent and language- 
independent programming and execution environment 
for distributed objects. 
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CORBA automates many common network programming 
tasks: 

object registration 
location and activation 

request multiplexing/de-multiplexing 5 
framing and error- handling 
parameter marshaling and de-marshaling 
operation dispatching 
Access to remote object services is transparent to the 
caller. Clients do not need to know: 10 
where the object is located 
its programming language 
its operating system 

any other system aspects that are not part of an object's 
interface 15 
Orbix Naming Service 

The Orbix Naming Service daemon provides symbolic 
lookup of servers on the network and is necessary to support 
the HOP protocol. 

HP Open View or Alternatively CMU SNMP 20 
library 

Functional Description 

The HP OpenView Network Node Manager 
(HPOVNNM) or CMU SNMP library product provide the ^ 
lowest-level network management infrastructure for deliv- 
ery of SNMP SET and GET requests and receipt of SNMP 
traps. This infrastructure will deliver GET and SET requests 
from the element management system Server to the SNMP 
agent and receive traps on the standard trap UDP port and ^ 
forward them to the SNMP Mediator. 
Role of HP OpenView Network Node Manager 

When used in the invention, HP OpenView Network 
Node Manager (HPOVNNM) is used as part of the element 
management system server 32 infrastructure. While only a 
subset of the HPOVNNM runtime system will be in active 35 
use, the full HPOVNNM system will be installed on the 
element management system server. The following major 
components will be installed. Those pieces of HPOVNNM 
that will be a part of the element management system server 
infrastructure are shown in bold typeface, 

ovspmd (OpenView System Process Management 
Daemon): This process must be running to enable 
client-interface status-checking programs such as 
ovstart to work. Since this monitor does not support ^ 
restarting terminated system processes, it will not be of 
particular use in the EM Server process management 
scheme. 

OVIicenseMgr: the license manager that controls the 
startup of critical HPOVNNM runtime components and 5Q 
the ovw browser application. 

ovtrapd (OpenView Trap Daemon): Receive incoming 
SNMP traps from each SNMP agent on a standard port 
and forward them to the postmaster daemon (see 
below). 55 

pmd (Postmaster Daemon): Serves as a general packet 
router in the HPOVNNM infrastructure. The pmd pro- 
cess receives traps from ovtrapd and forwards them to 
the element management system Object Server, which 
has registered to receive all traps. go 

ovactiond: the OpenView process that manages the asso- 
ciation of traps to UNIX-level actions as defined 
through the HP OpenView event management soft- 
ware. 

ovtopmd: the OpenView Topology Manager Daemon, 65 
which handles IP discovery and layout for the 
HPOVNNM topology database. 



,421 B2 

10 

netmon (Network Monitor): Discovers and monitors 
nodes on the network. It processes I CMP ping to 
monitor nodes, and it does simple SNMP periodic 
polling using the system group of MIB-2. 
snmpCollect: SNMP Collection Daemon which allows 
clients to define, via the HP OpenView Windows 
X-based GUI interface, SNMP MIB values that are to 
be collected periodically. It provides ways to define 
thresholds and associated actions (UNIX shell 
commands). 

ovw (OpenView Windows): The OpenView Windows 
X-based GUI provides access to map applications, an 
event browser, and a MIB browser, 
ovwdb (OpenView Windows Database): The OpenView 

Windows topology database manager. 
The HPOV SNMP API, a C-language interface to this 
runtime system, is provided as part of the HPOVNNM 
Developer's Kit and will be used to: 
Encode and decode SNMP packets. 
Set up and tear down SNMP trap sessions. 
The entire platform as described is installed and active is 
to support S^-party SNMP management applications written 
specifically for HP OpenView and making use of the ovw 
map framework. These applications are incorporated with 
minimal effort, since off-the-shelf 3 r</ -party applications use 
the ovwdb-based managed-object database rather than the 
CORBA-based Object Server mechanism. 
Administration 

Some administration of the HPOVNNM infrastructure is 
required if used instead of a CMU SNMP library package. 
Initial configuration: 

Definition of the local registration files used by 
HPOVNNM to determine which processes run and 
to define the specific attributes of each of these 
processes 

Definition of the trap configuration file: this defines 
what processing (including just logging) is per- 
formed on each trap received by the HPOVNNM 
infrastructure 

Inclusion of the HPOVNNM ovstart command in the 
appropriate RCC initialization file for automatic star- 
tup of infrastructure 
Configuration of the network license manager used by 
HPOVNNM 
Ongoing maintenance 
MIB updates 

License updates to the network license manager used 
by HPOVNNM 

Element Management System Server Components 
in Accordance With the Invention 
Object Sever 

The object server provides a way for client applications to 
receive information about network elements and other asso- 
ciated managed objects and to issue commands that are 
executed on the network element. To accomplish these 
functions, the object server provides the following services: 
(1) client session registration, (2) event distnbution and 
screening, (3) command management, (4) SNMP mediation, 
and (5) services specific to each managed object class. 

The object server is implemented as a single-threaded 
process using a central event queue. However, the architec- 
ture does not dictate this implementation. The architecture 
does require that the implementation be platform and oper- 
ating system neutral, and the concern is that a multi-threaded 
approach would have operating system dependencies. The 
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sub-components that comprise the object server could be 
implemented as separate processes. An example of the latter 
approach is the decision to implement a second major server 
component, the active alarm manager, as a separate process. 
As the element management system infrastructure evolves, 
other components that are currently part of the object server 
might be implemented as separate processes, if necessary 
and feasible. 

Various forms of inter-process communication may be 
used to communicate between these components, but the 
method recommended by this architecture is to use CORBA 
to remove platform-specific IPC from the implementation, 
and to provide for distribution of functionality to multiple 
processors if necessary for performance optimization. 

As shown in FIG. 3, the object server consists of the 
following set of components, each of which supports a 
particular service: 

Client Session Manager 130 maintains a list of active 
client sessions and audits for sessions that have termi- 
nated without notifying the manager. 
Event Distributor 140 provides event routing and distri- 
bution. Events include SNMP Traps (received via the 
SNMP Mediator) from network elements, commands, 
command acknowledgments, command responses, and 
events generated within the element management sys- 
tem. Clients of the Event distributor register a filter 
with the Event Distributor to request delivery (via a 
callback function) of Events matching the filter. 
Event Screeoer 150 is for use by the Object Server only, 
and supports screening events before they are seen by 
the event distributor for purposes of open-ended event 
correlation. 

Element Management System Command Handler 155 
tracks active commands and releases resources when 
the commands complete. The element management 
system Command Handler also coordinates the execu- 
tion of commands within the element management 
system. 

SNMP Mediator 160 provides translation between the 
MIB ASN.l format and the managed object notation 
used in this architecture. The SNMP Mediator also 
provides polling services for the SNMP Service 
Objects, and conversion of managed object commands 
(e.g. remove, restore) into appropriate SNMP set com- 
mands. 

Managed Objects: As shown in FIG. 3, each object that 
represents a network element or maintenance unit in a 
network element utilizing SNMP for its protocol (e.g. 
AP, DS1, EIN, LAN) is represented as a "SnmpMO" 
class object 170. A single instance of an object is used 
for all instances of that objects class in the system. For 
example, the AP service object provides attributes and 
methods for all instances of AP processors in the 
system. In addition to SnmpMOs, the architecture 
supports "Logical managed objects" that represent 
managed objects that aren't directly tied to a network 
element or maintenance unit. An example would be a 
"System** managed object class that would provide 
system level status and commands. 

Active Alarm Manager 

The active alarm manager 120 provides for client access 
to alarms currently active in the system and represents the 
element management system component of the client alarm 
list application. There are two communicating entities: the 
AP Active Alarm Table (AAT) managed object (of class 
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ApActiveAlarms) residing in the Object Server; and the 
Active Alarm Manager (AAM), a separate UNIX system 
process on the element management system that provides 
access (as defined by class AlarmManager) to client appli- 

5 cations. The AAM is implemented as a separate system 
process on the element management system to avoid block- 
ing the execution of the object server when potentially large 
volumes of alarm data must be delivered by the AAM (e.g., 
at client application startup. Since the AAT and AAM 

10 communicate across process boundaries, all interfaces 
between them are defined in IDL. Similarly, all interfaces 
offered by the AAM to client applications are defined in 
IDL. 

Alarms for all APs are represented in the AAT managed 
15 object, such that there is an alarm record for every class of 
maintenance unit that has an alarm currently active in an AP. 
Additional managed objects are introduced in the object 
server to track alarms in other maintenance units related to 
the AP (e.g. ApFrameActiveAlarms) or in another network 
20 element 14. As with the AAT, however, the alarms tracked 
by these managed objects will be reported to client appli- 
cations via the AAM process. 

The AAM system process contains a table of active alarm 
records which mirrors that of the AAT managed object. At 
initialization, the AAM registers with the AAT managed 
object for delivery of current alarm records and notifications 
of subsequent updates. Multiple clients can register alarm 
filters and callbacks for delivery of alarm records that match 
specified filter criteria. Client applications can change or 
cancel their specified filter criteria. 

UX Proxy 

Provides UX messaging interface to the IDS 79 to receive 
and process IDS triggers. A trigger is needed to notify the 
element management system when an AP is added to or 
deleted from the system. The element management system 
then polls the AP for its equipage data. 
ROP Formatter 

Formats the events in a format consistent with the ECP 
ROP formatting requirements, and sends the formatted event 
to the ECP for logging and printing at the ECP ROP. 

This component is a client that resides on the element 
management system server and provides the following func- 
tionalities: 

Registers with the Event Distributor for all events 
Utilizes the locale text formatting services to format the 

raw event as a TI/OP message 
Formats the events in a format consistent with the ECP 

ROP formatting requirements 
Includes in the message the appropriate alarm indication 
Sends the formatted event to the ECP for logging and 

printing at the ECP ROP 
Utilizes a new message class at the ECP for reports 
This mechanism will rely on a single message type for 
forwarding all element management system-generated 
TI/OP messages. The current interface from a mobile switch 
center (MSC) ECP ROP supports specifying Alarm Level 
60 (MAN, INFO, CRIT, MAJ, MIN). 
Command Line Interpreter 

The command line interpreter provides an ASCII com- 
mand language to allow the technician to enter commands 
and observe the command results. The input command 
65 syntax is the same PDS format used by a proprietary system. 
Command reports are also formatted in the same syntax as 
the existing proprietary system. 



35 



40 



45 



50 



55 



02/05/2004, EAST Version: 1.4.1 



US 6,363,421 B2 

13 14 

Provides ASCII based input language access to all com- helps to encapsulate rules regarding the behavior of man- 

mands for network elements (and their maintenance aged objects within the managed object class. This prevents 

units) supported by the element management system. the common practice of replicating this functionality (often 

Provides an acknowledgment to the input command to in varying ways) in the d ^f ™* 

indicate the disposition of the command. * management for the element. FIG. 7 shows an example of 

, . , , i 4 . . „ o how this approach can be used to define some of the 

Allows for multiple commands to be outstanding at one q ^ {{ ^ &hows faow i{ ^ be used tQ 

time derive specific types of AP managed objects. Note that this 

Provides command sequence numbers to correlate ^ on | y ^ exam pi e t o demonstrate the concepts described 

acknowledgments and responses with commands 1Q above 

Provides a final report indication for command responses. For SNMP based managed objects, the definition of the 

Infrastructure and Application Specific Components managed object and most of the managed object's attributes 

The architecture contains components that provide a can be derived from the definition of the ME3 55 (generated 

general infrastructure for network management and compo- by a toQ j that parses the MIB). Also, most of the code 

nents that are application specific. This section lists the 15 necessarv for translation between the MIB ASN.l format 

components from FIG. 4 in infrastructure and application and the EMAPI 55 object notation (performed in the SNMP 

specific categories. Some components consist of infrastruc- Mediator) can also be derived from the definition of the MIB 

ture and application specific code (e.g. command line 55 Automation of this translation will reduce maintenance 

interpreter) and are noted as such. 0 f m e system and will reduce development of new managed 

The following components are considered to be infra- 2 o objects when new network elements are added to the system, 

structure related: jh e c ^ ent interface to the services and the managed 

Object Server object attributes and methods is described in the EMAPI 55. 

CUent Session Manager The EMAPI 55 and managed object notation provide a 

Event Distributor and Screener consistent model of all managed objects in the network, 

element management system Command Handler 25 hiding the implementation details associated with the ele- 

SNMP Mediator ment manager platform from client applications (for 

Managed Object Base Classes (ManagedObject, example, clients do not need to know whether the underlying 

NEMO, SnmpMO, SnmpNE, see FIG. 7). protocol to the network element is SNMP, CMIP or a 

UX Proxy proprietary interface). Managed object specific logic is 

Active Alarm Manager 30 encapsulated within the managed object instead of scattered 

A . 4 _ _ av*' throughout various applications, thus simplifying client 

Client Acuve Alarm Browser Application application development. 
Client System Alarm Summary Application 

Client Network Element Detailed Status Application Mana § ed 0b J ect Notatlon 

ROP Formatter 35 A extinction is made m tnis model between the actual 

„ . objects present in the server to provide services for a class 

Command Line Interpreter. Portions of these componen s of J managed o5jects and the specific instances of those 

are specific to the application, e.g., the screen contents ed * objects (and their attributes). Instead of creating 

and layout will vary depending on the particular traits * ^ ^ mw&d objectfi ^ ^ system whicb 

of the application managed. 4Q caQ becQme hibilive on large element management sys- 

The following components are considered to be apphca- ^ whefe network elements a lafge numbef of 

tion specific: managed objects, a single service object is created to provide 

Commands and reports for the network element services for a class of managed objects. Specific managed 

Application-specific Service Objects of type Managed object instances and their attributes are referenced by use of 

Object, SnmpMO, SnmpNE 45 a set of object class identifiers and attribute codes. The 

definition of these managed object class identifiers and 

Managed Object Model attribute codes is part of the interface definition between all 

In this architecture, all resources and elements that can be service objects and their clients, 

managed are represented in the system as a managed object. Managed Object Identifiers 

Each managed object provides attributes, methods and noti- 50 A specific instance of a managed object is referenced 

fications that are used by client applications to manage the using its object identifier which consists of the object class 

object. In order to describe the managed object model used code and an instance identifier. The object class code is a 

by this architecture, the following terms are defined and used static enumeration or constant, and the instance identifier is 

in subsequent descriptions. an integer value (defined at run time based on configuration) 

All instances of a type of managed object share definition 55 that is unique to the object class. Although the instance 

of attributes, operations, notifications and behavior, but will identifier is unique to the managed object class, it is not the 

have attribute values that are unique for each instance of same as the logical number for that instance. Each managed 

managed object. This approach allows common behaviors object class provides methods for translating between the 

for managed objects to be defined in base classes, and for instance ID and an appropriate set of network element and 

specialized behavior to be placed in the managed object 60 unit identifiers. 

class for that specific type of managed object (while inner- For example, AP network elements are referenced by 

iting the common behavior and attributes of the base class). logical number in the system (e.g. 1 to n). The number of 

More specialized forms of managed object classes can be Aps in the system is not fixed at a specific number (such as 

developed by subclassing existing managed object classes, 8) but will be based on the equipage information found in a 

providing for reuse of existing classes. Subclasses will often 65 database . Each AP also can have some number of application 

add attributes, extend or restrict ranges of existing attributes, virtual machines, each identified by a logical number (e.g., 

and add or restrict operations and notifications. This concept RCS 1). 
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A specific instance of an application managed object is and software entities (for example, in later releases an AP 
referenced by calling a lookup function in the application's hosting RCS virtual machines could also have SS7 hardware 
service object to convert the AP network element instance and host IS-634 functionality), then a MIB supporting the 
identifier and application key into its associated instance ID. superset of possible managed objects must be constructed 
The combination of these two values in the object identifier 5 and made available for compilation into element manage- 
uniquely identifies a specific managed object instance. ment system runtime processes. This approach makes use of 

In many cases, the use of a service object for a class of automatic code generation, and is intended to save time 

managed objects will take the place of the object class code. when adding new objects to the element management sys- 

For example, the AP object class code is not specified by a tem. At the element management system, additional service 

client when requests are made through the AP service object. 10 objects must be created to support management of the 

Conversely, the AP object class code would be present in any instances of the new classes of managed objects (e.g. 

events sent to a client so that the client can identify the MMA). 
specific managed object instance that generated the event. 

Attribute Codes Portability 

Each managed object contains a set of attributes specific is ^ dcvelopmcat of this architecture must ensure port- 
to that instance of that managed object class. These ^ of ^ dicnt ^ gcrvcr OTmpoilcntSi can ^ 
attributes describe various maintenance, operational, con- accomplished ^ severa i ways . Machine and operating sys- 
figuration and measurement information about the managed tem (QS) depcndent ^ should be hi ddcn ^ much as 
object. Each attribute is defined with an attribute code that possMc (especially when there are multiple interfaces to it 
is local to the name space of the managed object to which it 20 ^ by placmg {{ vnappCT libraries. For 
belongs. For example, the AP managed object class will cxamp i C) the Elcme nt management system Logger class will 
have a State attribute (as will the RCS managed object - de objcct . orientcd wrap pers for all existing propriety 
class). Each attribute code is unique to the managed object ux logging serv i ces (UX_ELOG, UX_DLOG, 
class to which it belongs. UX_PLOG and UX^OG). This allows for platform 
Attribute Value Definitions 25 retargettmg by changing the implementation of the machine/ 
The type definition for any attribute value that is not of a QS d dent libraries with no impact on the calling func- 
basic "primitive" type (for example, short or octet) and is ^ Qr Interproccss commun i cat ion will make use 
used between the clients and the server must be defined in of indust stand ard software such as CORBA which is 
the IDL. The scope of these definitions may be limited to the available on most machine and 0 S platforms, 
managed object that uses them, or may be at a higher system 30 

level (for example, alarm level definitions would be at a Object Server Components 
system level). 

This section describes the major components of the 

Adding New Managed Objects Object Server in detail. Each of the components may be 

_ , . . , 35 represented as the element management system, processes 

When adding new types of managed objects in the system Qf bm afe lreated ^ geQeral components m this 

a choice must be made to create a new type of managed sectioQ ^ ^ q{ ^ descriptions provide general 

object service class, or to use an existing service class and e les (not ^ ci&c) since most of the components 

provide the ability to distingfiush between different versions ide aQ mfrastmcture that ^ t0 support the 

ortypesofmanagedobjectsmthatclass. The decision touse <q n q£ ^ QA&M fa addilkmal applications . 

a new class or extend an existing class will depend on how ^ m SessioQ Manager 

similar the new type or version of managed object is to the ^ CUent Scssion MaDager w j U maintain a list of active 

existing managed object. When using a common service ^ aQd a lications It ^ periodically audit 

class, an attribute of a that class could be used to provide ^ ^ ^ detect sesBfons ^ have away without 

discrimination between various versions/types of the same ^ . { tenninitiQn ( loss of conne ction). 

managed object. If a new managed object type is created, ^ foUowin functionality will be provided: 

any common attributes and functionality with other similar a 

managed object classes should be placed in a common base Interfax to clients for starting a session 

class lo reduce maintenance. To summarize the guidelines: treating a unique session identifier 

_ , ^, . . . the future, validate client security and permissions (see 

Create a New Managed Object for new maintenance unit 50 ^ « Securit » ? for a more detailed 

types that are unique to the system. discussion) 

Subclass an existing Managed Object (or move common ^ ^ ^ a 

functionality to a base class if it doesn't exist) for new t J f „ 4 , . 
maintenance unit types that provide common existing Interim to chents for periodic check-in (heartbeat) 
attributes. Note that this will still result in a new 55 Interface to other server components for registering inter- 
managed object type. An example of this is the Ethernet est in notifications of session/application termination, 
interfaces on the AP. They both provide common The components that have such an interest are: 
Ethernet functionality but there is an ethernet interface The Event Distributor, which is interested in all such 
node (EIN) and a LAN managed object. terminations 
Use version attributes for different versions of the same 60 Managed Object Service Classes, which are interested 
managed object. Support both hardware version and only in specific client session/applications, 
firmware revision attributes is needed. Periodic audit of active sessions/applications to see if any 
When adding new AP processors that support additional session/application has failed to check in recently, 
functionality (examples of this may be IS-634 applications) Sessions/applications that have failed to check in 
new types of managed objects will be defined to manage the 65 within a reasonable (to be determined in design) 
new types of objects within that type of AP. If all AP amount of time will be removed from the session 
processors are capable of hosting the additional hardware manager's active session/application list 
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Notification to registered entities when a session/ those of the event filter (given above). In addition, the 

application has been ended via the callback notification event header will contain: 

interface described above. A time stamp indicating when the event was generated 

Event Distributor and Screener Provide delivery of traps to clients using the client- 

The Event Distributor is responsible for filtering and 5 supplied callback function (for events that match their 

routing of all events in the system. A client that wishes to be supplied filter criteria) 

notified upon the occurrence of one or more ^ Evenl Distributor will play no role in event throttling: 
than ambute^ge notifications) reps^rs a filter wU the ^ SNMP agent. 
Event Distributor specifying catena to be matched against . & e 
whenever an event occurs. Examples of clients include the Auditing , ... , A 
Summary Alarm/Status Manager, ROP Formatter, Managed 10 Support cleanup of the filter list, through audits performed 
Objects, and clients issuing manual maintenance requests. by other Object Server components. This support is provided 
No formatting of events is performed within the Event through the interfaces described above or via internal call- 
Distributor— this is left to the application. Events are typi- back mechanisms. For example, when the Client Session 
cally generated as a result of a trap from an SNMP agent, but Manager removes a session and/or application from its 
can also be generated by element management system 15 internal structures, it notifies the Event Distributor via a 
components on the same machine, or even by other legacy callback, at which point the Event Distributor removes all 
network elements. The Event Distributor may be imple- filters associated with the session and/or application, 
mented as a set of objects within the Object Server. Filters associated with commands need to be cleaned up 

The Event Screener supports screening of events before under several circumstances: 
they are seen by the Event Distributor for the purpose of 20 When the final report indication is seen in a command 

simple, open-ended event correlation. The Event Screener event 

supports the same interface (although not available to When the trap containing the final report indication is lost 

clients) as the Event Distributor, but is only for use within Th e Event Distributor will receive a notification when 

the Object Server. either of the above circumstances are detected, at which 
The following subsections show the functionality pro- 25 point the filter matching the affected command or commands 

vided by the Event Screener and Event Distributor. will be removed. 

Client Registration and Filtering Command Handler 

Provide an IDL interface (Event Distributor Only) for Because various resources are utilized within the element 
registering filters based on the following: management system server to process managed object 
Session and Application ID commands, the Command Handler must track active com- 
Callback object, used to deliver events to the interested mands and release resources when the commands are corn- 
registrant, pie ted. Active commands are modeled as another class of 
Filter object containing a specification describing managed objects within this system, and the Command 
events to be delivered to the client. This filter allows Handler represents the service object for all instances of 
for a limited set of parameters that provides for active commands. The Command Handler provides the 
specification of a set of event attributes that may be centralized tracking and management of these commands, 
combined to limit the set of events. Specific values Since command responses are delivered via unreliable 
for event attributes can be given or a special don't- SNMP traps, an audit of command activity between the 
care value that can be used to ignore the attribute. network element and the Command Handler must be per- 
The event filter will contain the fields in the list below. formed. 
Note that not all these fields must be set; those that do not Command Block 

matter can be marked don't-care as described above. Command blocks will contain at least the following fields: 

Event Category Command Sequence Number 

Network Element instance ID and class code Session Identifier 

Network Element alarm level 0b j ect i nsta nce Identifier (for example, which AP? Or 

Maintenance Unit instance ID and class code which DS1?) 

Maintenance Unit alarm level Command Type 

Command ID (client session ID ana command ' r f . 1X 

>_ . Command Qualifier (optional) 
sequence num *) 50 Some commands may require additional arguments. Since 

Provide an IDL interface for clients (Event Distributor ^ command bk)ck ^ defined ^p^y, it is simple t0 

only) and other Object Server components to explicitly additioDa i arguments. 

cancel a specific filter. Command Responses/Acknowledgments 

Provide a means for Object Server components to remove Each agem must generate an acknowledgment trap in 

all filters associated with a specific session and appli- 55 response t0 each com mand request containing the originat- 

cation. ing session identifier and command sequence number along 

Provide an efficient method to store client registrations an acknowledgment value indicating whether the com- 

and filter criteria and an efficient method to examine mand request jg mV alid or could not be processed, processed 

these filter criteria on incoming traps. as requested with no further response, or in progress with 
Event Receipt 60 additional response pending. In the latter case, one or more 

The Event Screener receives events from the SNW command response traps will be generated which also 

Mediator (which receives traps from SNMP agents and contain originating session id and command sequence 

translates them into EMAPI 55 event headers) number, along with a response sequence number and final 

The Event Distributor receives events from the Event report indication. Since UDP messages may be received 

Screener and other Object Server Service Objects. 65 out-of-sequence, the response sequence number may be 

Match an incoming event header against each stored event used by a client application to reorder multiple responses for 

filter. The event header will contain fields that match the same command. 



02/05/2004, EAST Version: 1.4.1 



US 6,363,' 

19 

Command Filter Cleanup 

The final report indication will be used by client appli- 
cations to note when a command-initiated action is 
completed, and will also be used by the server to automati- 
cally de-register event filters associated with that command. 5 
Each agent will support an active command table listing the 
session IDS and command sequence number of all com- 
mands in-progress. This table will be audited periodically by 
the server to initiate filter removal when final report traps are 
lost. 10 

SNMP Mediator 

This functionality provides translation between the 
EMAPI 55 class and attributes and the IP addresses and 
object identifiers of the SNMP MIB. It is also responsible for * 5 
formulating appropriate SNMP requests (SNMP SET 
requests for maintenance requests, SNMP GET requests for 
polling and auditing) and routing responses back to the 
requesters). It queues SNMP requests and ensures that no 
single Network Element SNMP Agent is overwhelmed by a 20 
burst of requests. Note that there is no client access to this 
component; it exists solely for internal use within the Object 
Server. 

SNMP to EMAPI 55 Translation 

This functionality will perform translations between the 25 
EMAPI 55 Object Class, Instance Class and Attribute Code 
notation and the SNMP IP Address, SNMP MIB Object 
Identifier (OID) and zero or more SNMP variable bindings. 
It may be implemented as a set of objects and methods 
within the Object Server. 30 
The types of translations this service must perform are: 
EMAPI 55 Command object to SNMP Command Block 
EMAPI 55 Poll-Request object to SNMP Get 
EMAPI 55 Instance ID/Class Code to SNMP IP Address 35 
SNMP Get Response to EMAPI 55 Poll-Response object 
SNMP Trap to EMAPI 55 Event Header 
SNMP IP Address to EMAPI 55 Instance ID/Class Code 
Object Server Interface 

Provide an interface to managed object classes in the 40 
object server to support: 

Auditing: the periodic polling of configuration data and 
persistent attributes (persistent in element management 
system memory) that the Object Server tries to keep on 
the server at all times (these attributes are stored in 45 
memory for use by multiple clients, and are not saved 
over a reboot of the element management system). 
Polling: the periodic polling of attributes that are 

requested by one or more EM Clients. 
One -Time Status Requests: a single request for an 

attribute or attributes. 
Command Execution: issuing commands using SNMP 
SET requests. 

SNMP Interface 5S 

The SNMP Mediator handles all interfacing with SNMP 
agents on network elements. The SNMP interface consists of 
Attribute Polling, Configuration Auditing, Command 
Execution, SNMP Retry Mechanism, and Trap Delivery. 
Attribute Polling 60 
Use the HPOV SNMP API or the CMU SNMP library to 

establish an SNMP session to each AP agent 
Use the EMAPI 55 to SNMP Translation component to 
translate between EMAPI 55 notation and the appro- 
priate SNMP get request 65 
Translate the response to an SNMP get request to EMAPI 
55 notation and route it back to the associated managed 
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object, which then checks for and propagates only 
those values which have actually changed 
Provide control over the number of outstanding get and 
set requests to an agent. This is necessary to prevent 
overloading the socket at the agent. 

Configuration Auditing 

AP equipage is maintained via recent change. Configu- 
ration information for sub-network-element level compo- 
nents is maintained by each AP agent. When more than one 
managed object instance may be associated with an AP (e.g. 
RCS), the respective managed object is defined by a MIB 
table which is indexed by one or more configuration 
attributes (e.g. cell number). Associated with each table is 
another MIB object identifying the current number of table 
entries (the table count). Configuration information for any 
table may be retrieved by sending a GET request to the agent 
for the table count, and one or more GET-BULK requests to 
retrieve index information (also known as keys) for all valid 
rows in the table. The SNMP Mediator will perform a 
periodic audit of each table in this manner to report current 
configuration information to each associated managed 
object. 

Command Execution 

The SNMP Mediator will use the EMAPI 55 to SNMP 
Translation component to translate from EMAPI 55 com- 
mands into the appropriate MIB command block settings. 
The SNMP Mediator will translate EMAPI 55 commands 
into the appropriate MIB command block and issue an 
SNMP SET. 

Command Queing 

Because SNMP requests are sent via UDP and may be 
received by an agent out of sequence, a command request/ 
response convention between manager and agent will be 
utilized to insure that an agent will respond only once to a 
single command (i.e. SET operation) regardless of the 
number of retries which may be generated. The manager will 
maintain a separate command SET queue for each network 
element. The size of the command SET queue per network 
element is preferably tunable. Only one SET request for any 
given network element will be pending at any one time. That 
is, a command protocol data unit (PDU) will not be sent to 
the associated agent until the SET response from the previ- 
ous command is received. Once the SET response has been 
received, other commands are initiated and sent to the 
associated agent. Each PDU contains a monotonically 
increasing request id, which will be examined by the agent 
on all SET requests. If the id is greater than the last 
processed, the PDU is presumed to contain a new request 
and will be acted on accordingly. If the request id is equal 
to the last processed, the agent will assume the duplicate 
packet is the result of a retry, and will return the response last 
generated. If the id is less than that last processed, it is 
presumed to be a duplicate packet for a command to which 
the manager must have already received a response (or 
timeout), so the packet is ignored. 

Failure Handling 

When the SNMP Mediator receives a SET request from a 
managed object for delivery to a network element that is 
known to be not responding, the request will still be pro- 
cessed as received. If an associated PDU can not be sent, a 
negative acknowledgment will be generated locally, and 
returned to the originating client via the event distributor. 
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SNMP Retry Mechanism 

Since SNMP relies on UDP as the underlying transport 
protocol, SNMP GET, GET-BULK, and SET operations can 
be lost. To recover from losses, the SNMP Mediator will use 
a mechanism for retrying SNMP transactions that will be 
consistent for all GET, GET-BULK and SET operations and 
will conform to the interface prescribed by the HPOVNNM 
SNMP library or the CMU SNMP library. For further 
information, see the reference to HPOVNNM or CMU 
SNMP library, previously incorporated by reference herein. 
A predefined maximum number of retries may be attempted 
for each request. There is a tunable timeout that is logarith- 
mically increasing (defaults to a maximum retry delay of 12 
seconds per request is suggested). If a response for any 
request is not received after the maximum number of retries, 
each of the managed objects associated with this network 
element is notified of the loss of communication and a local 
event is generated, resulting in an alarmed output message 
being delivered to the ECP ROP. State values in the internal 
status tables will be set accordingly, and these changes will 
be propagated to registered clients via callback. The polling 
queue for the network element is made idle until a subse- 
quent audit or any trap indicates that the agent is back online. 

Trap Receipt and Delivery 

The SNMP Mediator will receive traps from SNMP 
agents. The outline of this mechanism is as follows: 

At initialization, open a trap session with the HPOV 
SNMP infrastructure 

For each trap, translate the SNMP trap PDU into an 
EMAPI 55 event header 

Deliver each EMAPI 55 event to the Event Screener for 
filtering and delivery to registered clients. 
MIB-to-IDL Mapping 

A means will be provided to automate the maintenance of 
M1B changes and the corresponding EMAPI 55 managed- 
object notation. An engine that includes an ASNI MIB parser 
will be used to generate IDL and other files that depend on 
the MIB. The goal will be to minimize the amount of 
hand-crafted and maintained IDL. 
MIB Conventions 

MIB conventions will be denned and documented in 
coordination with the development of the AP agent. 

Service Object Description and Infrastructure 

A service object exists for each class of network element, 
maintenance unit or logical object within the system. As 
shown in FIG. 4, these are labeled SnmpNEMO and 
SnmpMO Class Objects. Each service object instance pro- 
vides services for client application access, and maintains a 
view of the attributes (as needed) for all instances of 
managed objects in that class. Example service objects 
include the AP, RCS and DS1. Examples of logical service 
objects include System and APSummary. FIG. 8 shows 
managed object classes and their containment relationships 
" that may be used to manage the AP. FIG. 8 also shows some 
example Service Objects that may be added in the near 
future to manage other telecommunication network ele- 
ments. The OA&M shown can host the element manage- 
ment system. 

To maintain attribute values and provide client notifica- 
tions for attribute changes, each service object maintains a 
status table dynamically sized according to current configu- 
ration data and client polling needs. Information in this table 
will be identified through a class dictionary containing 
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attribute codes and type information, available via common 
interface definition to both server and client code. For 
example, the AP object may contain attributes for mainte- 
nance state. Client applications will gain access to that state 

5 information for a specific AP via class methods which accept 
instance identifiers and attribute codes. The service object 
provides a centralized place where network element status is 
recorded. Instead of each application polling for attributes it 
needs, the service object manages a list of the registered 

to clients and the attributes they are registered for. The com- 
bined set is then polled for by the SNMP Mediator. Addi- 
tional class methods will be provided for performing opera- 
tions specific to the unit type, such as remove, restore and 
diagnose. The specific protocol used for communication 

15 with the network element is specified by the service object. 
The SNMP protocol is used for communication between 
service objects associated with the AP and the AP network 
element. Other managed object classes could be added that 
utilize a different protocol and encapsulate that knowledge 

20 in the managed object class. FIG. 9 depicts an AP service 
object and the data it contains. It also shows an example ECP 
managed object that could use a protocol other than SNMP 
for cornmunication. 

25 Client Notification and Request Response 

Each service object will provide methods for client access 
to attributes of its managed object instances. In addition to 
requesting the current value of attributes, clients can register 
for notifications of any changes to attribute values. Client 
30 access to attributes and registration for attribute notification 
is specified in terms of the following. 
A set of attributes for a specific instance of a managed 
object 

35 A client callback function for delivery of initial attribute 
values and subsequent changes 
All attribute values are delivered to the client by the client 
supplied callback object reference. A sequence of attribute 
code and value pairs are sent as an argument to the callback 
40 object reference. For the initial notification, the sequence 
contains the values of all requested attributes. For subse- 
quent notifications of attribute changes, the sequence con- 
tains only those attributes that have changed. 

Client Command Request/Response 

Each service object for a class of network elements or 
maintenance units provides member functions to implement 
requests for operations on specific instances of the class of 
network element or maintenance unit. For example, to 

50 remove a DS1 unit from service in the AP, the remove 
method of the DS1 service class is invoked. As with any 
other client requests, the client must have created a session 
prior to performing this operation. The specific instance of 
the maintenance unit and any command specific parameters 

55 must be specified. The operation will return a command 
sequence identifier (commandSeq) that is unique to the 
client session. The command sequence identifier is present 
in the header for all subsequent events (Acknowledgment 
and Command responses) for the command. 

60 Once the operation is validated at the server, a filter is 
registered for the client with the Event Distributor for all 
events that match the client's session and the command 
sequence identifier associated with the command. After 
successfully registering the event filter, a command request 

65 is sent to the SNMP Mediator where the instance is con- 
verted to the appropriate IP addresses and MIB command 
block values and generates the appropriate SNMP Set 
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request. Command acknowledgments and command These attributes are updated by trap notification from the 

responses are transmitted from the SNMP agent by means of network element (and are audited by a low level periodic 

SNMP Traps. At the server, they are converted to Events and audit poll controlled by the Snmp Mediator). Maintenance 

routed to clients with matching event filters. Note that there state is delivered by state change notifications, and alarm 

is a retry mechanism for SET requests where the element 5 level attributes are delivered by alarm set/clear notifications, 

management system does not receive an associated SETRSP Configuration Attributes 

(detailed in the SNMP Mediator section) but no retry is & 

attempted when a command fails (such as in the case where These attributes constitute configuration related informa- 

a failover was in progress). tion - ™ csc attributes are updated as a result of an event 

System initiated commands and responses will be routed io notification of configuration change or » the ; managed objecL 

similarly, using unique system session identifiers and call- ™*n a configuration event notification is received noting 

back functions^ example of this type of command would an insert or update of ^^"^ Jhc managed 

... , , , , „,„,.„ rr\D\ ™h* r * > object performs a single request to get the current values of 

inc hide a request to output the system status (OP) where a all attributes for the specified (this is also known in SNMP 

1S as trap directed polung). When the configuration event 

and generating the responses. These commands are pro- P configuration delete, the managed object per- 

cessed within the element management system server and f > f J *\ 

, , . . f c\T\MTi • tt-.^ forms the associated deletion of the instance. As with 
no. by a network elemen through the SNMP interface The 

element management system se^ermus tge ^ com- ^ ^ Snm Mediator y (in fact 

mand acknowledgmen and command response . event. ..self P P X » ^ ^ 

since ,t is responding to the command internally. apLogical i d . Note Vt some attributes marked as Config 

The network element agent is responsible for providmg an J e when ^ sfm? reboots Therefore> the 

acknowledgment trap indicating if the command request was £ ^ ^ n6vcr issu6 confi chaQgc nodfi . 

accepted. Results of the command are then delivered from on ^ attributes ^ ar6 cat6goriz6d M ^fig 

the network element agent by a series of 1 or more command ^ m a ed object ^ their values ^ 

response traps. The last command response trap contains a other cQnfi ^i^s when the config notification is 

last response or final report indication which is to be used for a new q£ me ma ^ objcct 
within the server to detect the end of the command and to 

release server resources associated with the command (e.g. Audit Attributes 
event filters). Since the command responses could be lost, a ^ value of mese attr i DUtes are only maintained through 
low level audit of command activity must be performed a periodic low level audit. Examples of this type of attribute 
between the manager and the network element agent. The aR , the active commarJ d table command session and corn- 
audit does not require that the agent keep command response maad g^^ce num ber. 
information. The audit only checks to see if the command is 

still running at the agent. If a command response or trap is Polled Attributes 

lost there is no recovery to regenerate the lost response. For 35 xh e current value of these attributes are only maintained 

cases where the network element cannot generate a com- jf a cuen t is registered for notifications of changes to the 

mand acknowledgment, or the acknowledgment is not attribute. These attributes are polled for at a 15 second 

received at the element management system server, the polling rate by the SNMP Mediator. Ac example is the AP 

element management system server is responsible for gen- sysUpTime attribute. 

erating an appropriate acknowledgment back to the client. 40 

The following summarize cases where the element manage- Internal Attributes 

ment system Server is responsible for generating the These attributes are based on internal data or derived from 

acknowledgment event back to the client: other attributes. An example is the isolated attribute in the 

1. Can't transmit command block SET PDU to agent AP network element. Its value is based on an isolation 

2. No SETRSP received from the agent (after repeated retry 45 indication detected by the SNMP Mediator when commu- 
of SET request) nication is lost to a network element (or subsequently 

3. SETRSP from agent indicates an error (such as an invalid restored). For SNMP based managed objects, all attributes 
object identifier) that are not internal, directly represent an associated MIB 
In all other cases where the agent receives the SET request attribute. 

and is able to "understand" its contents the agent is then 50 Service Object Base Class Functionality 

responsible for generating the acknowledgment (either posi- Much of the basic behavior of each object is present by 

tive or negative). means of inheriting base classes that contain the specific 

*u * manager functionality. For example, client registration and 

Object Attributes polling will be defined in base classes shared across all 

The following types of attributes can be associated with 55 service objects. The following sections describe these com- 

each managed object. For each category of attribute, the morj behaviors available to all service object classes, 
source of the attribute data differs (e.g. network element 

trap, network element polling, element management system Managed Ubject Base Class 

local data). It is not required that all managed objects This class provides definitions of the basic interfaces that 

support all categories of attributes, instead the presence of 60 all managed objects must support. This includes providing 

the attributes is based on the needs of the managed object client interfaces for things such as managed object configu- 

(for example, some managed objects have no state attribute, ration notification and attribute update notification. Specific 

but have an alarm attribute. service objects would all inherit this base class. 

Persistent Attributes 65 NE Managed Object Base Class 

State and alarm attributes for managed objects are always This class (derived from managed object base class), 

maintained even if no clients are registered for the attribute. provides network element specific functionality on top of the 
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basic managed object class. This includes providing client Handles poll responses from the SNMP Mediator. When 

interfaces for network element configuration notification. It a set of polled data is delivered (via server callback 

is responsible for handling network element related equi- function) attribute values must be compared with the 

page notifications from configuration data services (AP current values in the attribute table. When the value has 

equipage changes) and notifying the SNMP Mediator of 5 changed, the value in the attribute table is updated and 

these changes. The SNMP Mediator must be notified of clients must be notified of the change. Note that if more 

these changes in order to provide appropriate routing and than one attribute has changed for a managed object 

translation between the Managed Objects and the network instance, the changes will be grouped and delivered to 

element. Specific network element service objects would all each registered client on a managed object instance 

inherit this base class, to basis. 

Client Notification Registration Trap Directed Attribute Polling Management 

Each service object must manage a list of clients and the p or ne t WO rk elements utilizing SNMP, all alarm, configu- 

attributes for which they are registered. This list must ra tion changes and basic state changes (including non 

contain a session handle, the list of attribute codes, and the 15 a i armec j maintenance states) are delivered to the manager 

instance identifiers) for specific managed object instances. fj 0m tne Agent through the use of an enterprise specific 

This functionality must also provide methods to efficiently SNMP trap. These traps are received by the SNMP Mediator 

search this list based on attribute code and instance identifier where they are translated into EMAPI 55 Events and passed 

so that registered clients can be notified of changes. Client along t0 the EveDt Distributor. They are then delivered to all 

registration must be coordinated with the Client Session 20 c ^ ents ma t nave registered a filter matching the data in the 

Manager to provide for graceful cleanup when abnormal associated Event. The Summary Alarm/Status functionality 

client termination is detected. G f eacn c iass of objects registers a filter with the Event 

The Client Registration Functionality Distributor to request delivery of all alarm and state change 

Provides interface to clients for attribute registration events for all instances of objects within its class. When a 

given the following parameters 25 alarm or state change event is received by the Summary 

client session id Alarm/Status Manager, the attributes for the appropriate 

managed object instance identifier (specific id, range, instance are updated, the summary attributes for the class are 

or all in class) updated, and all clients registered with the object for state 

set of attribute codes change notification on the affected attributes are notified via 

callback function for delivery of changes 30 their client callback functions. 

Provides general container and data structures for man- Registers appropriate filter with Event Distributor for all 

aging a list of client registrations events on instances of this managed object class 

Provides methods for construction and delivery of client (alarms, state changes, configuration notifications). 

callback with attribute code/values. 35 Handles events from the Event Distributor. When a trap is 

Provides interface with client for de-registration received, attribute values in the Event are compared 

Provides interface with Client Session Manager for with me current values in me attribute table. When the 

de-registration when abnormal client termination is value has changed, the value in the attribute table is 

detected via audit. updated and clients must be notified of the change. 

™ i. j a« -U . w * 40 Interfaces with SNMP Mediator to perform low frequency 

Polled Attribute Management ^ rf fa ^ maQaged obj&ct ^ 

Attribute polling is needed for element management sys- associated with traps, 

tem initialization (e.g., upon element management system Handles low frequency audit poll responses from SNMP 

initialization, the only way to obtain status is through Mediator, 

polling), attribute values that are not trap-directed, and 45 

audits (i.e., UDP is an unreliable transport and as such, traps Client Interface Components 
may be lost). Trap-directed attributes are stored on the 

element management system in memory for use by multiple The following sections describe the components present 

clients. There may also exist other attributes whose value is on a client of the element management system server to 

only obtained through polling, and that polling will only be 50 P rovide the cUent interface t0 ^management Specific 

initiated when a client has informed the object that it is client interface style and content will be addressed after the 

interested in notifications of state changes to those variables. architecture with input from human factors and element 

In that case, the object must request that the SNMP Mediator management system engineering. In addition to making the 

poll network element at regular intervals (15 seconds) to client interface as easy to use as possible, the client interface 

determine if any of the variables of interest have changed. If 55 must retaia Parities ™* the maintenance model 

a change is detected, registered clients must be notified by such that little retraining of the end client (technician) is 

means of a client callback. These polled attributes are also necessary. Sample Web pages can be found in the attach- 

stored in memory. The manager of these attributes are as ments to this document. 

follows: ^ of Netwofk Element Te i net Access 

Maintains the attribute table (allocation of attribute table, 60 

instance identifier management, changes to the attribute Direct cut-through access to the AP is required to perform 

table based on configuration changes) system administration and some configuration functions, 

Informs the SNMP Mediator of the current set of and as a means to access the AP command line interpreter if 

attributes that are to be polled. When a client registers the element management system is not operational. To 

(or de-registers) the set of attributes that must be polled 65 provide this access, the client platform must support a telnet 

for may change. If it does, the SNMP Mediator must be application and a suitable terminal emulation to run a visual 

informed. editor such as vi. On an X terminal, an xterm terminal 
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emulator and use of the telnet application will be sufficient. 
On the Microsoft Windows platform, use of an X terminal 
emulator will provide the same access as an X terminal, or 
the Windows telnet application on a PC may be used. 

WEB Browser 

The primary client interface is provided by an HTML web 
browser. Both Netscape navigator and Microsoft Internet 
Explorer are to be supported. The web browser must support 
the execution of Java 1.1 applets and at least HTML version 
3.2. The following client terminal configurations must be 
supported: 

X Terminal with Netscape browser running on the ele- 
ment management system. 

Sun workstation with Netscape browser running on work- 
station. 

PC (Windows 95 or NT 4.0) with either Netscape or 
Microsoft IE running on PC. 

WEB Pages 

To provide web based network management access for the 
AP, web pages providing the following functionality must be 
developed. FIGS. 10, 11, 12 and 13 show sample page 
layouts): 

1. Top level page: Initial entry to system. Presents a menu of 
options and potentially high level system status. 

2. Network page: Hosts AP system level summary applica- 
tion 

3 . AP page: Hosts AP detailed NE status page for a single AP. 
Aversion of the page is constructed "on the fly" based on 
the AP logical number in the URL. The AP logical number 
and any other parameters are passed to the AP detailed NE 
status applet. 

4. Alarms page: Hosts the Alarm list applet. 

Note that page layout and navigation is determined by 
working with human engineering factors. 

Client must be able to: 
1. Access each page directly. Secure access (through web ID 

validation) must be provided for the initial access to these 

pages, but not for requests for subsequent pages as long 

as the same browser session is used. 

Java-based GUI Infrastructure 

This section describes base components that are necessary 
for implementing the AP specific GUI applets. A number of 
these components (especially the GUI components) may be 
satisfied (or based upon) commercial 3"* party products (for 
example Rogue Wave JWidgets, or Microline's Grid 
widget). Also, 3 rd party non GUI container and algorithm 
classes (either Rogue Wave or JGL for example) should be 
considered to enhance the set that comes with the Java 
Development Kit. 

The following sections describe applications that use this 
architecture. 

AP Summary Application 

This application provides summary information for all AP 
processors in the system. The summary information consists 
of the highest alarm level, administrative state and equipage 
status of all AP processors. Any changes to the configuration 
of displayed summary information are updated on the dis- 
play within 30 seconds of the change. State changes are to 
be displayed within 15 seconds of the state change in the AP. 
In addition to presenting summary and equipage 
information, the application supports navigation to detailed 
status pages for each of the AP processors. It also provides 



10 



15 



20 



25 



30 



35 



40 



55 



60 



a pop up menu (and any necessary dialog boxes) for execu- 
tion of AP commands (e.g. RMV AP). A command response 
area or dialog box is also provided for display of command 
responses. 

This application initiates a session with the element 
management system server (through the Client Session 
object) and registers with the network element service 
objects (the AP object) for the configuration information and 
attributes that it needs to provide a display of the AP network 
element summary (e.g. highest alarm level and status 
summary). An initial set of attribute values is delivered to 
the client and any subsequent changes to those attributes are 
delivered (from the summary alarm/status manager in the 
service object). Note that only the changed attributes are 
delivered in the subsequent callbacks unless the client 
requests a "reload" of attributes. 

A sample Network Web page can be found in the attach- 
ments. 

Network Element (NE) Detailed Status Application 

This application presents a detailed view of the status of 
maintenance units within an AP network element. Any 
changes to the configuration of displayed summary infor- 
mation are updated on the display within 30 seconds of the 
change. State changes are to be displayed within 15 seconds 
of the state change in the AP. This application initiates a 
session with the object server (through the System object) 
and registers with the AP service objects (specific network 
element instance and maintenance units) for attributes that it 
needs to provide a display of the AP element status. An 
initial set of attribute values is delivered to the client and any 
subsequent changes to those attributes are delivered (from 
the attribute manager in the service object). Note that only 
the changed attributes are delivered in the subsequent call- 
backs unless the client requests a "reload" of attributes. The 
detailed status application may also provide context sensi- 
tive command execution through the use of pull down (or 
pop up) menus. The interface for command execution and 
display of command results is the same as the interface 
described in the "Command Handler" section above. 

A sample AP Web page can be found in the attachments. 
Alarm List (Active Alarm Browser) Application 

This application provides an alarm browser interface to 
active alarms within the system. The client can specify a 
filter to limit the set of alarms (e.g. by network element, 
alarm level etc). The application registers it's filter and a 
callback function with the active alarm manager through the 
EMAPI 55. An initial set of active alarms matching the filter 
criteria is delivered to the client along with subsequent 
updates to set or clear alarms. Upon graceful termination the 
client disconnects from the active alarm manager (or an 
internal audit in the active alarm manager detects this and 
cleans up). 

A sample Alarms Web page can be found in the attach- 
ments. 

Locale Text Formatting Services 
This service provides the infrastructure for multiple 
human language support. This service is used by any appli- 
cation that interacts with an end client through display of 
text: this includes the ROP formatting process, the web- 
based client applications, and any local logging on the 
element management system. 

The following functionality will be provided: 

Access to a database of text formatting strings used by 

clients for formatting 
Lookups are based on an integral key and a corresponding 
ASCII string is returned 
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The database contains key and ASCII values and will 
reside on disk. The storage format and caching mecha- 
nisms will be designed so minimize lookup speed. 

Both local and remote clients can be served. 

Adherence to X/Open CAE (XPG4) source message file 5 
format. 

Commands and Reports 

Each managed object class will adhere to the interface 1Q 
specified by the managed object base class (provide for 
client attribute registration, notification, configuration reg- 
istration and notification), and will manage equipage, alarm 
and status for all instances of managed objects in that class. 
Each class will also provide methods to implement managed 15 
object specific commands. These methods will incorporate 
appropriate argument validation (e.g. range checks, target 
network element is equipped before the command is 
executed. 

Besides the AP generated reports, the element manage- 20 
ment system will generate reports for the following condi- 
tions: communication is lost with an AP, communication is 
established with an AP (cold start trap), and all APs are out 
of service. 

25 

Overload Control 

Overload control in the element management system 
server is accounted for primarily in the design (as opposed 
to here in this document). Specifically, status requests 
(polling, auditing and one-time GET requests) are limited by 30 
the number of simultaneous HPOV sessions supported by 
the element management system and the size of the tunable 
sliding window managed for each AP. Further, the event 
stream is limited by the throttling mechanism implemented 
by each SNMP agent. On the client side, the element 35 
management system will support a limited number of active 
client sessions, each of which may run a limited number of 
applications. The bottom line is there won't be enough 
network or client generated traflic to warrant the develop- 
ment of additional overload controls for the first phase. 40 

Additional development should extend overload controls 
to safeguard against an uncontrolled event stream, and 
monitor and restrict the number and scope of client requests 
associated with each application. 

The following areas of concern have been identified and 
will be used as the starting point to examining overload 
control: 

Client Overload: 

Registering for too high a volume of data 5Q 
Creating too many sessions: note that adequate 
resources are currently allocated for internal server 
sessions 

High-frequency callbacks (traps for example) 
Server Overload: 55 
Too high a volume of polling from SNMP Mediator to 
NE agents 

Trap floods: too many traps received over short period 
from NE agents 

Software Version Management 60 

The plan of record for overall AP/element management 
system/ECP software version management is as follows: 

For software retrofit for other applications, the element 
management system Server and the AP are retrofited to 65 
the same new version of element management system 
software. 
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At element management system Software Update: 
The element management system Server is updated first 
The APs are updated one at a time 
The element management system Clients will detect the 
element management system Server is down, and 
will need to reinitialize when the element manage- 
ment system Server is back online. 

For element management system SUs, the element man- 
agement system software on the element management sys- 
tem server must be compatible with the old version and new 
version of software on the AP. To support this compatibility, 
the element management system server is required to sup- 
port MIB versions j and j+1 simultaneously. Element man- 
agement system version management extends to element 
management system client applications as well, which must 
have knowledge of the MIB version on a given AP and be 
able to act accordingly. 

During a software retrofit application and element man- 
agement system Server SU, the element management system 
Clients will go down and will need to re -initialize once the 
element management system server is back up. The defini- 
tive requirements for element management system GUI 
Client version management will be described in the element 
management system GUI Client Capability Requirements/ 
High-Level Design document 

The design of the MIB is that it contains a very detailed 
description of the element management system/AP inter- 
face. The MIB is intended to serve as much as possible as a 
single element management system/AP interface definition. 
As such, its details may need to be modified more frequently 
than at each Generic Retrofit. The SU approach will not 
guarantee that an element management system Server run- 
ning a different MIB version than a corresponding AP SNMP 
Agent will be able to conduct error-free operations, but 
rather will enumerate the possible ways a MIB could change 
from one release to another and will specify the way version 
mismatches in each case will be handled and the kind of 
error handling that will be needed. The overriding goal is to 
maximize a technician's ability to perform the method in 
accordance with the invention on any available AP even if 
that AP is not running the same MIB version as the element 
management system server. 

Security 

This functionality provides a method of client based 
access control of network elements, maintenance units and 
operations on network elements/maintenance units. Upon 
startup, a client application must register with the server by 
providing identification of the client host, port, client, and a 
password. The server retrieves the client record from local 
data services and returns a session object to the client noting 
the client's access permissions. This information may be 
used to provide some level of access control in the client 
application (e.g. deactivating menu element management 
system for maintenance operations that are not allowed). In 
any case, all client requests are validated at the server. Each 
managed object class requires the session identifier as a 
parameter to each public method. The access permissions 
associated with the session are examined before authorizing 
client execution (e.g. remove operation). Note that there is 
a predefined "system session" with global access permis- 
sions for use by infrastructure components which make use 
of the same interface definition. 

The version of SNMP that will be used by this architec- 
ture is SNMP V2c. This version of SNMP provides no 
further security enhancements over the community name 
based security in SNMP VI. It provides no mechanism to 
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authenticate the source of a management message, or to 
prevent eavesdropping on the messages on the network. 
Because of this, it is strongly recommended that the network 
that is utilized for the element management system to AP 
SNMP traffic be a closed network and not part of the service 
providers public LAN or intranet. 

The command line interpreter application (which resides 
only on the element management system server) is appli- 
cable to any client with a login on the element management 
system server. Thus, the client based access control 
described above provides a means to restrict access on a 
command/client basis. 

Major Sub-components of the AP 

Afunctional block diagram of the AP is shown in FIG. 14. 

SNMP Agent: Provides the interface to the element man- 
agement system Server using the SNMP protocol and a 
MIB defined specifically for the AP. Sends AP events 
and command acks/responses to the element manage- 
ment system Server as SNMP TRAPs; responds to 
requests for managed object data (SNMP GETs); 
passes command requests (SNMP SETs) to the Com- 
mand Handler. 

AP MIB: An SNMP MIB defined specifically for the AP. 
Contains the definition of all AP objects to be managed 
from the element management system Server, as well 
as the definition of all AP TRAPs to be sent to the 
element management system Server. 

Agent Configuration File: contains values need by the 
Agent to communicate with the Manager, which resides 
on the element management system Server. 

Event Handler: responsible for both the filtering and 
forwarding of events to the SNMP Agent. In response 
to events that are generated, updates the Network 
Element Status Table with data that is to be "remem- 
bered" by the AP (so that the element management 
system Server may query or poll for it later). 

Event API: AP applications use this API to generate an 
event (state change, alarm, informational message, 
configuration). The event is passed to the Event Han- 
dler. 

Network Element Status Table (NEST): a repository for 
all status that the element management system Server 
may query for. Current status, including state variables 
and list of outstanding alarms, for each Managed 
Object will be maintained here. In addition, the list of 
outstanding commands will be maintained here. 

NE Status API: an interface for writing to and reading 
from the Network Element Status Table. 

Event Configuration File (ECF): text file, (possibly edit- 
able by the technician), which defines which events are 
to be logged locally on the AP and/or passed to the 
SNMP Agent for transmission to the element manage- 
ment system Server. As per requirements, there will be 
a set of events that will always be logged and forwarded 
to the element management system Server — the tech- 
nician will not be able to modify these. There may be 
other events defined (as the development phase 
proceeds) which may be edited by the technician. The 
ECF also defines X.733 values (e.g. severity) associ- 
ated with alarms and informational messages. 

Admin Log: file containing a customer-viewable log of 
events generated on the AP; which events are logged is 
controlled by the ECF. 

The following sub-components are considered part of the 
AP infra-structure software. 
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Command Handler: manages all commands that are to be 
executed on the AP. Interfaces to a command source 
(also known as a Command Handler Access Point, or 
CHAP), such as the SNMP Agent, the AP Text Client, 
or the ECP Agent via the Command/Response API. 
Responsible for triggering and monitoring the com- 
mand to be executed via the RAP API. Generates the 
command acknowledgment. Routes the command 
acknowledgment and command responses back to the 
command source. Maintains list of active commands in 
the NE Status Table. 

Command/Response API: interface between a command 
source and the Command Handler for the purpose of 
issuing commands and obtaining command acknowl- 
edgments and responses. 

RAP API: a general API for spawning a process and 
obtaining the results of the process execution. 
Generally, RAPs will be used to carry out a mainte- 
nance command on an AP resource. RAPs may spawn 
other processes, if necessary. 

Text Command Interpreter: text-based command client 
for generating commands and receiving responses 
locally on the AP. Intended to be used when the element 
management system Server is unavailable. 

IDS-AP: maintains the data tables of the IDS on the AP; 
receives triggers, representing changes in data, from the 
IDS on the ECP. 

IDS (Configuration) Data: a repository for AP configura- 
tion data obtained from the ECP via IDS-AP. 

IDS API: an API for obtaining configuration data pro- 
vided by IDS-AP. 

ECP Agent: interface to Status Display on the ECP; 
interface to IDS-AP for processing triggers indicating 
change in data. Passes triggers on to interested appli- 
cation processes. 

Audit Controller: audits status and alarms among RCC, 
NEST, and resource managers (e.g. CCM) 

AP State Monitor: detects and reports RCC-related state 
changes and alarms. This includes state changes and 
alarms reported by Resource Monitors RCC process 
monitoring software. 

SNMP Agent 

The element management system interfaces to the AP via 
the SNMP Agent. A MIB is used to define the interface 
between the element management system Server and the 
Agent and is common to both the element management 
system Server and the Agent. The Agent is described here 
and the MIB is described in the following section. The Agent 
communicates with the element management system Server 
using the Internet standard Simple Network Management 
Protocol (SNMP) (see Internet document RFC-1157) via a 
standard UDP/IP port. In this architecture, the intent is to use 
SNMPv2c, which provides enhanced capabilities over 
SNMPvl, such as the GETBULK operation. 
SNMP provides three basic management functions: 
GET (also GETNEXT and GETBULK): obtains data 
from a managed system (retrieves attributes associated 
with a managed object, as defined in the MIB). The 
managed system must respond to a GET with a GET- 
RESPONSE. 

SET: usually used to make modifications to the man- 
aged system. The managed system must respond to 
a SET with a SET-RESPONSE. In this architecture, 
SETs are used to trigger commands to be executed on 
the AP. 
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TRAP: a way for the managed system to send asyn- 
chronous notifications to the Manager. 
SNMP Agent Functionality 

The SNMP Agent will perform the following basic func- 
tions: 5 

I. Receive SNMP packets sent by the SNMP Manager at the 
element management system Server and process each one 
as follows: 

A, GET/GET-NEXT/GETBULK packet: Obtain the cur- 
rent values of the managed object attributes requested 10 
in the packet by accessing either the Network Element 
Status Table or the Configuration (IDS) Data, as appro- 
priate. The requested attributes and their values are 
stored in a GET-RESPONSE packet and returned to the 
Manager. 5 

B. SET packet: Map an SNMP SET request into a 
command request message, as defined by the common 
Command/Response API. The command attributes, as 
specified in the SNMP packet and defined in the MIB, 
will be mapped in to corresponding message elements. 2Q 
The message will be passed to the Command Handler 
via the Command/Response API. 

The Agent will send a SET-RESPONSE back to the 
Manager. If the SET request was invalid such that the 
Command handler could not determine a command to 25 
run, or if the command could not be passed to the 
Command Handler, the SET-RESPONSE will indicate 
an error. The Manager must interpret a SET 
RESPONSE error and generate a command acknowl- 
edgment indicating an error occurred. 30 

The Agent must allow for the case where the Manager 
may send an identical SET request. This can occur if 
the Manager does not receive the SET-RESPONSE 
(lost). The Agent will remember the last SET request 
processed for a given client session (the client session 35 
info is defined in the MIB as common attributes for all 
commands) and will only pass the command to the 
Command Handler if the request is new. If the request 
is old, the Agent will simply send another SET- 
RESPONSE to the Manager. 40 

II. Receive messages from the Command Handler and 
process each one as follows: 

A. If the message is a Command Acknowledgment, map 
it into a Command Acknowledgment TRAP packet. 
The MIB will define a Command Acknowledgment 45 
TRAP that will be used for all commands. A command 
acknowledgment will take the form of a simple value to 
indicate the status of the command, such as the com- 
mand was rejected, timed-out, is complete, or is in 
progress with command responses to follow. 50 

B. If the message is a Command Response, map it into a 
Command Response TRAP packet. The MIB will 
define a common Command Response TRAP block 
that will be passed back in all command responses. In 
addition to the common Command Response TRAP 55 
block, there will be specific definitions in the MIB for 
each type of command response than can be generated. 
Note that there is no provision made to save Command 
Responses in case they are lost (perhaps the command 
response handling at the element management system 60 
Server can report on lost responses). Nor, is there any 
provision to guarantee that responses are returned in the 
correct order. 

III. Receive messages from the Event Handler and process 
each one as follows: 65 
A. Map the particular event into a corresponding TRAP 

packet. There are four possible types of events that can 
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be received by the Agent and each event type will be 
mapped to a specific TRAP, as defined in the AP MIB. 

1. State Change: indicates a change in value of one or 
more of the variables associated with a managed 
object. Managed object states will be maintained in 
the NE Status Table and the Manager may query the 
Agent for any or all states associated with the 
managed object. The Agent will map the variables 
and new state values in the event message into their 
corresponding MIB object identifiers and values in a 
TRAP packet, and send the packet to the Manager. 

2. Alarm: indicates a condition of an unexpected nature 
which requires special and persistent technician noti- 
fication. May also be used to indicate a clearing of 
such a condition. Each alarm is associated with a 
managed object and has a definition specific to that 
managed object in the MIB. There is an alarm block 
defined in the MIB that is common to all alarms. 
Alarms, like managed object states, will be main- 
tained in the NE Status Table, and the Manager may 
query for active alarms. The Agent will map the 
alarmed event into the common MEB alarm block 
plus the specific attributes defined for the managed 
object. 

3. Informational message: is similar in substance to an 
alarm, but is a condition that does not require the 
persistence of an alarm. The intent of an informa- 
tional message is a condition which requires logging 
(say at the element management system Server and/ 
or on the ROP) but is either not considered important 
enough to be maintained as an alarm (i.e. persistent 
view to the technician), or is a condition which can 
not be automatically retired when the condition 
disappears. An alarm defines a condition which must 
be able to be retired, either automatically or as a 
result of some technician action. The Agent will map 
the Informational message event into the common 
MIB Informational message block plus the specific 
attributes defined for the managed object and send it 
to the Manager. 

4. Configuration Change: indicates that the configura- 
tion data for a given managed object has changed in 
some way (i.e., the managed object was created or 
deleted, or the configuration data associated with the 
managed object was updated). The Agent will map 
the Configuration Change event into the common 
MIB Configuration Change block and send it to the 
Manager. The Manager is then responsible for que- 
rying the AP to obtain the new/updated configuration 
data. 

IV. The Agent will throttle TRAPS going to the element 
management system Server so as not to overwhelm the 
Manager. Throttling will be based on a fixed maximum 
rate coming from the AP. The throttling performed by the 
Agent will be priority-based, such that command acks and 
responses would take precedence over configuration 
changes, which would take precedence over alarms, 
which would take precedence over informational mes- 
sages. The details of TRAP throttling will be specified 
during the design phase. 

SNMP Agent Initialization 

In order to communicate with the SNMP Manager on the 

element management system Server, the Agent requires 

certain information: 

1. The IP address of the SNMP Manager is required in order 
to send SNMP TRAPs; a standard hostname will be 
assumed to exist in the /etc/hosts file on the AP and the 
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Agent will obtain the IP address of this host on startup. 
Default IP addresses will be setup at staging of the AP. 
2. The SNMP read and write community strings. Commu- 
nity strings are a form of SNMP security: the strings that 
the Manager will send must match what the Agent is 5 
expecting in order for the Agent to allow a GET (read)/ 
SET (Write). These strings will be obtained from a 
command-line option when the Agent is started. 
Command-line parameters are specified in the RCC con- 
figuration file. 10 
The SNMP Agent will exist as part of the Element 
Management Infrastructure Platform Virtual Machine 
(PVM) on the AP, and as such will be started by the Reliable 
Cluster Computing infrastructure. 

Upon startup, the SNMP Agent will perform the steps 
necessary to gain access to the NE Status Table and Con- 15 
figuration Data; determine the Manager's IP address (as 
stated above); and will send a standard SNMP Cold Start 
TRAP to the Manager. 

The Agent will respond to SNMP GETs on the standard 
Internet "system" group objects. This is required by the HP 20 
Open View package that is being used on the element man- 
agement system Server. 
APMIB 

The AP MIB is the data definition shared between the 
SNMP Manager on the element management system Server 2 s 
and the SNMP Agent on the AP. It contains the definition of 
Common attribute blocks ("headers"), such as those 
defined for commands, command acknowledgments, 
alarms, etc. (see "MIB Conventions" below). 
All state variables, commands, command responses, 30 
alarms, and informational messages associated with the 
objects that are to be managed from the element 
management system Server. The managed objects are 
intended to include the AP itself, RCS virtual machines, 
the ethernet, etc. 35 
Objects required for auditing, such as the list of active 
commands (so that the element management system 
Server may audit its view of outstanding commands 
with the AP's view), 
MIB Conventions 40 

As mentioned previously, several conventions will be 
applied to the MIB to support this architecture. They are 
listed in the following sections. 
"Binary" versus "ASCII" Attributes 

The intent is that the attributes defined in the MIB will, in 45 
general, be defined as binary values, as opposed to ASCII 
strings. This allows the text-formatting of the attribute 
values (at the element management system Server) to use 
locale text formatting (so that the text appears in the appro- 
priate human language). 50 

SNMP agents preferably support the above variable. It is 
used by the Manager to determine whether this is an MIB 
(supporting the other interface conventions described in this 
section), and also to provide a versioning mechanism to 
support MIB changes. Upon initialization, the Manager will 55 
attempt to perform a GET operation on this variable. If it 
does not exist, the Agent does not support the enhancements 
required by this architecture. 
Common Command Block 

To support command requests, the MIB must support a 60 
specific set of variables to allow for all parameters for 
command execution to be specified in an atomic operation. 
This set of variables is called the command block. The 
command block provides a way to "register** a command 
request with an identifying tag that is used to route the final 65 
response (delivered by a TRAP) to the originating requester. 
The command block will contain such parameters as: 



A session ID thai relates the command to a particular 
client session. 

A command sequence that makes the command unique 
within a particular client session. 

An object instance identifier (e.g. "7" for an "RCS" 
managed object) to identify the particular instance of 
the object that the command is to be performed on. 

A command operation (e.g. REMOVE). 

Additional parameters specific to the command are not 
part of the common command block. 
Common Command Acknowledgment and Command 
Response Blocks 

In order to route Command Acknowledgments and Com- 
mand Responses back to the originating client, the TRAPs 
that are generated to produce acks and responses must 
contain the common command block attributes (see above) 
from the initial command request. Command Responses 
must also contain a response sequence and a flag indicating 
last response. The common command block attributes will 
be passed to the Command Handler by the SNMP Agent and 
must be returned from the Command Handler to the Agent 
(i.e. this must be part of the Command/Response API), so 
that the Agent can return them in a Command Response 
TRAP. 

Common Alarm and Informational message Blocks 

Alarms and Informational messages will have a common 
attribute block defined. Attributes such as alarm level, alarm 
cause, alarm ID (a unique value per outstanding alarm) will 
be defined. 

Common Configuration Change Event Block 

There will be a common attribute block defined for all 
Configuration Event TRAPs. Attributes such as the managed 
object instance identifier and the configuration operation 
(insert, update, delete) will be defined. 
Unit Hierarchy Addressing within the MIB 

SNMP MIBs currently provide only one method to struc- 
ture data: a simple two-dimensional table with scalar-valued 
entries. This limited way of structuring MIB variables does 
not directly support the more complex structure of a network 
element such as a cell site. A cell site has many units, each 
of which has a set of variables specific to that unit. The units 
are structured in a hierarchy. 

To reference a specific attribute (or a set of attributes) of 
a sub-unit lower in the hierarchy, a multi-column key 
consisting of an identifier for each unit in the hierarchy will 
be used (e.g. to reference a sub-unit like CCC 2, CCU 1, the 
last two digits of the SNMP object identifier would be 
"2.1"). The SNW GETNEXT operation supports a conven- 
tion (which must be supported by the Agent) to request an 
attribute by specifying the multi-column key as an object 
identifier. 

Note: Currently, there has been no such unit hierarchy 
deemed necessary for the AP managed objects. 
Event Generation and Processing 

Applications on the AP are responsible for generating 
events to reflect: 

Current status and alarms associated with AP managed 
objects. 

Changes in configuration data associated with AP man- 
aged objects. 

Informational messages that may be of interest to Net- 
work Management applications. 

In order to prevent inconsistencies, it is assumed that one 
and only one application will be responsible for the status 
and alarms of a particular managed object instance, and thus, 
be responsible for maintaining an accurate view of the 
managed object at all times by use of the Event API. 
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The following sections describe the major components Current managed object status, on a per-man aged-object- 
involved in event generation and processing. instance basis. 

Event API List of outstanding alarms, on a per-managed-object- 

The Event API provides a mechanism for applications on instance basis, 

the AP to generate events, and communicate these events to 5 Actiye Command Tab i e , so that the SNMP Agent has 

the Event Handler for possible recording, logging and/or access t0 the list of commands that are currently 

forwarding to the element management system Server. The outstanding from the element management system 

API includes: Server, for audit purposes. 

The definition of all possible events in the system. Each 

event will be classified into one of the four possible 10 Network Element Status API 

types of events, as discussed earlier in this document: . . , KT , 

r\ . , • c i„ Provides a mechanism to read and write the Network 

state change, alarm, informational message, or conngu- 

4 - u Element Status Table. The API blocks readers while the table 

ra ion c ange. ^ be - upc j a ted so that the data is kept consistent (e.g., by 

A means to initialize the API. Internally, the API will use . a s hore y Supports "wildcard" clearing of alarms 

the UX inter-process communication library to send ^ describe d above in the "Event API" section. Hie intention 

messages to the Event Handler. fa ^ the Event Handler ^ be me one an d only one 

A means to pass the alarm text associated with a given a pplication that will use the write API, while other 

alarm occurrence. The text will be encoded in a implications, such as the ECP Agent and the SNMP Agent, 

machine- and language-independent form for transmis- 2Q ^ me read ^pj 

sion to the element management system. The means to 

encode text will be provided by a National Language Event Configuration File (ECF) 

Support (NLS) library. ^ ^ (possibly editable by the technician), which 

A means to clear all alarms previously generated by this defines whkh eyents afe lQ ^ j d ^ Qn lfae ^ 

application. This is intended to be used when an 25 and/of d tQ ^ SNMP Agent for transmission to the 

apphcationre-initializes and must clear all outstanding ekment m ment system Server . Events that ^ 

alarms related to aU managed objects for which it is ed tQ ^ ^ d iQ {hQ management 

responsible. This capability may or may not be needed sysiem Seryer ag defined by ^ system requirements ^ 

in Genenc 13. not be ^y ow&6 l0 be changed. The ECF also allows the 

A means to clear all alarms associated with a particular 30 technician to the X.733 values associated with alarms 

managed object instance. This is intended to be used and i n f onnat ional messages. An ECF-checker application 

when a particular managed object is initialized or ( e g sn ell/awk) will be written to prevent invalid modifica- 

brought in to service. For example, there may be tions t0 tne fi j e 
several outstanding alarms on a DS1 object related to 

in-service operation. When the DS1 goes out -of- 35 Admin Log 

service, the application managing the DS1 may want to . , ^ TT „ . 4 

clear ail outstanding alarms on that DS1. An ASCII file, written by the Event Handler that contains 

Event Handler events that are to be logged as defined by the ECF, with 

The Event Handler will exist as part of the Platform common fields in a fixed format. This file will be based on 

Virtual Machine on the AP, and as such will be started by the 40 the existing OMP Admin logging mechanism. The fields for 

Reliable Cluster Computing infrastructure. Alaim entries will match the content and order of the fields 

The major functions of the Event Handler are: that appear on the element management system Server 

I. Read the Event Configuration File to determine which Alarm List application and will be tab delineated. The 
events are to be recorded (attribute changes and alarms), amount of data contained in the Event Log will be main- 
loeged, and/or passed to the SNMP Agent for transmis- 45 tained through the standard logfile mechanisms. Access to 
sion to the element management system Server. The ECF the Event Log will be through standard mechanisms (cut- 
also defines whether an event is an alarm or an infonna- through to the AP, use of a standard editor). 

tional message, and the X.733 values associated with EMAPI 
alarms and informational messages. 

II. Monitor the ECF (e.g. UNIX stat system call) on a regular 50 "^T^ 6 ^ . c . /l3 w C * tM ^ c Q 

i. • * j * * u • *u nr-i The Element Management System (EMS) provides a 

basis to detect changes in the ECF. . . . . & . , J . ' f, _ , , 

TfI zr . s - v AD nnA framework for monitoring and controlling network ele- 

III. Receive messages from applications on the AP and ^ . , . , j i • i . • .i_ _i 
i^^i m s ments. Each physical and logical component in the network 

process each one as totlows: fa modeled as a managed object, which the Server makes 

A. If the event is to be logged, do so. visible tQ distributed client applications through the facilities 

B. If the event is one which requires recording (an 0 f tne Common Object Request Broker Architecture 
attribute change or an alarm), update the NE Status (CORBA). EM Clients need only be concerned about the 
Table using the NE Status API. attributes and operations defined for each application man- 

C. If the event is to be passed on to the element manage- aged object, and not the details of network-level protocol 
ment system Server (by default, all events will be 6Q and the server infrastructure required to support object 
passed), send it to the SNMP Agent using the UX services. The following is the Element Management Appli- 
inter-process communication library. cation Programming Interface (EMAPI) 55 in accordance 

with the invention utilized by EM Clients. 



Network Element Status Table 



EMAPI Object Definitions 



A repository for all non-configuration data that the ele- 65 
ment management system Server may query for. This FIG. 15 shows all of the interfaces visible to client 
includes: applications.: 
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FIG. 15 does not depict process or processor boundaries, 
which are made transparent by the client and server object 
request brokers (ORBs). Application services are provided 
through object interfaces formally defined in the CORBA 
Interface Definition Language (IDL). 

The service objects resident on the server with which 
client applications interact are shown in Table 1 in FIG. 16. 

Client applications which register for real-time status 
updates or notification of events, alarms or configuration 
changes must provide a reference to a local callback object 
which the Server will use to propagate information asyn- 
chronously. The callback interfaces defined in the EMAPI 
are listed in Table 2 shown in FIG. 17. Classes which 
implement these interfaces must be defined and instantiated 
in Client code. 

Data Representation 

There are several fundamental data types defined in the 
EMAPI, which fall into one of two categories shown in FIG. 20 
18. 



Session Management 

Each EM Client session is logically associated with a 
login. Session identifiers are assigned by the EM Server 
when the client registers with the user session manager at 
initialization. Each Client application is logically associated 
with a session. Application identifiers are assigned by the 
Client. For the Element Manager Graphical User Interface, 
each "window" will be assigned a unique application id. 
Note that each Client is required to register a periodic 
heartbeat to validate for the Server that its associated session 
is still active. 

The UserSession service object provides the following 

interfaces: 
start 

This method must be invoked by a Client at initialization 

to register a new session, 
stop 

A Client invokes this method to notify the Server that the 
associated session is terminating, and that all resources 
utilized by any of the applications associated with the 
session should be released. 

stopApplication 

A Client uses this method to notify the user session 
manager of termination of a single application, 
heartbeat 

This method must be invoked at least every UserSession- 
::HeartbeatPeriod seconds to avoid a timeout condition 
which, when detected by a Server audit, will result in the 
release of all resources utilized by any application associated 
with the respective session. 
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Managed Objects 

A managed object (MO) is an abstract representation of a 
physical or logical resource which may be managed by the 
EMS, such as a network element, maintenance unit or data 
link. The EM Server will implement one application-specific 60 
service object for each type of physical or logical resource 
to be managed. Each of these service objects defines a set of 
attributes which identify managed object properties, as well 
as the operations which may be performed on a specified 
managed object instance. (The decision to provide access to 65 
instance information through a single "service object" stems 
from the fact that current ORB implementations become 



unstable when managing large numbers of remote 
references.) The diagram shown in FIG. 19 depicts the 
relationship between Client, application-specific service 
object, and the internal Server representation of managed 
object instances. 

Each managed object service class is uniquely identified 
by a ClassCode. Each managed object instance is uniquely 
identified by an Instld. Any object instance in the system 
may be uniquely referenced by a managed object identifier 
(Oid), which is the combination of ClassCode and Instld. 

Managed object status information is reported by a ser- 
vice object as a sequence of attribute code-value pairs. Each 
attribute value is defined as a union of all of the EMAPI 
fundamental data types described in the section herein 
pertaining to DATA 

Representation 

Configuration information is reported as a sequence of 
ConfigData structures, which are defined to contain: 

network element instance id 
managed object instance id 

a managed object key list reported as a sequence of 
attribute-value pairs (when length is greater than 0, the 
key list usually specifies one or more Logicallds) 
Each managed object service class must implement the 
MO interface, which defines the following configuration and 
status services: 
viewconfig 

A client uses this method to obtain the current EMS view 
of the managed object configuration for a specified 
network element instance. Note that the reserved 
instance identifier Anylnstance may be used to obtain 
configuration information for all network elements. 

notifyConfig 

A client may also register for managed object configura- 
tion information via callback. In this case, an initial 
view is returned with a notification type CONFIG_ 
IN1T 

Subsequent changes are reported with type CONFIG_ 

CREATE or CONFIG_DELETE. 
cancelNotify 

A client uses this method to cancel registration for man- 
aged object configuration notifications associated with 
a specified client application. 

getPersistent 

A client may use this method to retrieve the set of attribute 
codes (SeqAttrCode) identifying all "persistent" data 
maintained by this service object. The associated 
attribute values for each managed object instance are 
stored and kept current irrespective of any client 
requests. 

viewStatus 

A client may invoke this method to obtain the EMS view 
of the current values for a specified set of persistent 
attributes for a specified managed object instance. 

getStatus 

A client may use this method to register for a snapshot of 
current status information. This interface differs from 
the previous one in that the requested attribute list may 
specify any managed object attribute codes — not just 
those associated with persistent data, and the informa- 
tion is returned via client status callback (StatusCB). 
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startUpdate Event category defined to be one of the following: 

A client may also register for an initial view and notifi- Alarm Set 

cation of any updates to a list of selected attributes for Alarm Clear 

a specified managed object instance. In this case, an Command Acknowledgment 

initial view is reported via client callback with a 5 Command Response 

notification type STATUS_INIT. Subsequent changes Configuration Change 

are reported with type STATU S_CHANGE. Note that Informational Message 

managed object instance deletions are reported only Initialization 

through configuration change notification (to avoid a Stale Change 

potential flurry of client callbacks when a network 10 Network element object identifier 

element is unequipped). Network element alarm level (meaningful only for alarm 

stopupdate set) 

A client uses this method to cancel registration for man- Maintenance unit object identifier (if applicable) 

aged object status updates. 15 Maintenance unit alarm level (meaningful only for alarm 

getlnst set) 

A client may use this method to obtain a managed object A command identifier (Cmdld) defined as a user session 

instance identifier for a specified network element id & command sequence number (meaningful only for 

instance id and managed object key list. command acknowledgment & response) 

Note that each method requires a client session applica- *o 2. Event data defined as a sequence of structures which 

tion identifier (SessionAppId) to validate user access. contain: 

In the case of configuration or status change notifica- A ClassCode of a managed object, network element or 

tion registration, this identifier is also used to keep track descriptive entity 

of the additional server resources utilized while the a sequence of attribute code-value pairs 

client application is active. 25 Client applications may request a copy of the event 

stream, as processed by the event distributor, filtered on 

Network Element Level Managed Objects information specified in the event header. Filter wildcards 

Each network^lement level managed object must also are implemented with «out-of-band" values: 

implement the NEMO interface which defines additional 30 Any Category 

network-element level configuration services: Any Class 

viewNEconfig Any Instance 

A client may invoke this method to obtain the current Any Alarm 

EMS view of the network element configuration. rj m d 

notify NEconfig 35 The Table 3 described in FIG. 20 summarizes which filter 

A client may also register for network element-level criteria are valid for each event category: 

managed object configuration information via callback. The event distributor processes filters by examining the 

In this case, an initial view is returned with a notifica- specified category and AND'ing together valid criteria, 

tion type CONFIG_INIT. Subsequent changes are Clients may simulate OR operations by registering multiple 

reported with type C0NF1G_CREATE or CONFIG_ filters. 

DELETE. The EvtDist service object implements the following 

cancelNEnotify client interfaces: 

A client should use this method to cancel registration for registerFilter 

network element managed object configuration 45 A client uses this method to register an event filter. A filter 

updates. identifier is returned. 

Note that each method requires a client session applica- cancelFilter 

tion identifier to validate user access. In the case of con- ^ c ^ ent invokes this method to remove a specified event 

figuration change notification registration, this identifier is g lter> usmg me fi] ter returned from the associated 

also used to keep track of the additional server resources 50 registration. 

utilized while the client application is active. Note mat eacn mem od requires a client session applica- 



Descriptive Entity Objects 



tion identifier to validate user access. 

Alarm Manager 



Application objects of this type are defined to provide 
type and attribute information for abstract entities, such as 55 Alarm information is reported as a sequence of Alarm- 
data communicated between the EMS and network elements Data structures which contain: 

which are not part of a managed object description (e.g. ClassCode of a managed object which defines a 

SNMP trap definitions and command groups). Descriptive network-element specific alarm record. Note that in the 

entity objects provide no implementation— they are defined g ret re i ease 0 f the EMS, only one network element 

and known by client applications at compile time. 60 active alarm table ^ defined (ApActiveAlarms). 

Event Distributor A of alarm , re0 ? rds ' e * ch of which " Dt ™? " 

alarm instance identifier and sequence of attribute 

An event is reported as a combination of the following: code-value pairs. 

1. A header, which contains information of most general 55 Client applications may request a copy of all active alarms 

interest: filtered on any combination of the following: 

Time of the event Network element 
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Maintenance unit 
Alarm level 

Similar to the interfaces provided by the event distributor, 
out-of-band values may be used to represent wildcards. 

Since managed object instance information may not be 
available at the time an alarm is reported, the actual alarm 
filter criteria are specified in terms of logical identifiers. 
Logical IDS are integer values which represent the logical 
numbers of devices and interfaces (e.g. AP 4). The correla- 
tion between logical ids and managed object instance iden- 
tifiers is provided in the configuration information made 
available by each managed object service object, and 
through the utility method getlnst. Refer to the section on 
Managed Objects for additional details. 

The AlarmManager client interfaces are written specifi- 
cally for the Active Alarm List application: 

requestAlarms 

A client invokes this method to register a filter for active 

alarms. 
changeFilter 

A client may invoke this method to change filter criteria. 
refreshAlarms 

A client may invoke this method to refresh the active 

alarm list. 
cancelAlarms 

A client should invoke this method to de-register a filter. 

All operations except for de-registration return all active 
alarms filtered on the specified criteria. Also, each of these 
methods requires a valid client session application identifier 
to validate user access, and to keep track of the additional 
server resources which may be utilized while each client is 
active. 

Exceptions 

Exceptions are used for consistent and structured error 
handling in both the EM Server and Client. 

The CORBA specification defines many system excep- 
tions: 

BAD_PARAM 

INV_OBJREF 

NO__PERMISSION 

BAD_OPERATION 

NO_RESPONSE 

OBJ_ ADAPTER 

Refer to "The Common Object Request Broker: Archi- 
tecture and Specification" for an exhaustive list of mnemon- 
ics and the associated exception descriptions. 

Vendor-specific object request broker exceptions are also 
defined (using the Minor identifier of the SystemException): 

NO_IT_DAEMON_PORT 

LJ CENCE_EXPI RED 

♦ ♦♦ 

Currently, the EMS uses Iona's Orbix product. Refer to 
the "Orbix 2.1 Reference Guide*'" for an exhaustive list of 
mnemonics and the associated exception descriptions. 

In FIG. 21 an EMAPI-specific exception is defined, with 
an EmapiExceptionCode containing one of a plurality of 
values. 

In most cases, exceptions will be treated as fatal errors by 
a Client resulting in termination of all associated applica- 
tions. 

Those skilled in the art who now have the benefit of the 
present disclosure will appreciate that the present invention 
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may take many forms and embodiments. Some embodi- 
ments have been presented and described so as to give an 
understanding of the invention. It is intended that these 
embodiments should be illustrative, and not limiting of the 
present invention. Rather, it is intended that the invention 
cover all modifications, equivalents and alternatives falling 
within the spirit and scope of the invention as defined by the 
appended claims. 

APPENDIX A 

DEFINITION OF TERMS 



Alarm 



Active Alarm 
List Browser 

Applet 
ASN.l 



APCC 



25 



AP EMS 
Infrastructure 



30 



API 



Applet 
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Attribute 
Attribute Code 

Class Code 

Client 

Callback 

Function 

EMAPI 
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IDL 
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Instance 
Identifier 



JAVA 



65 



A condition, usually of an unexpected nature, which 
requires special and persistent technician notification. 
A JAVA applet displaying the current active alarms in 
the system for all managed objects. A sample Active 
Alarm List Browser Applet can be found 
in Attachment 2 on the Alarms Web Page. 
Abstract Syntax Notation One: A formal language used 
to define syntax. In the case of SNMP, ASN.l notation is 
used to define the format of SNMP 
protocol data units and of objects. 
Application Processor refers to a commercial computing 
system that provides generic computing facilities. 
Application Processor Cluster Complex: the highly- 
available platform, or cluster computing environment, 
in which an AP in the cluster can run the application 
services of another AP in the cluster should that AP fail. 
The OA&M software architecture components that reside 
on the AP to support the APCC OA&M architecture. 
These include the MIB on the AP, the SNMP agent 
on the AP, the event handler, and other components 
described in section 4 of this document 
Application Programming Interface: a well-defined 
software interface, usually abstracting the details of the 
underlying implementation from the client of the 
interface. 

small Java program which is dynamically downloaded 
by a Web browser and executed by its virtual machine. 
Though a Java applet has access to many of 
the services provided by the browser execution 
environment (e.g. audio, network access), it is also 
restricted by the browser Security Manager (e.g. no 
access to local file system). 

A property of a managed object. An attribute has a value. 
A code that identifies a specific attribute of a managed 
object class. 

An integer value which uniquely identifies a managed 
object class. 

A function passed by the client to the server that is used 
by the server to deliver asynchronous notifications of 
attribute changes, configuration changes 
or event notifications. 

Element Management Application Programming 
Interface 

Generally, an autonomous notification. We have defined 

four types of events that the AP can generate: alarms, 

reports, state changes, configuration changes. 

An international standard suite that defines the interfaces 

required to attach base stations from one vendor 

to the MSC of another vendor. 

Interface Definition Language: A C++- like notation for 
describing CORBA object interfaces. IDL is used to 
describe any resource or service a server 
component wants to expose to its clients without 
regard to its implementation 
language or operating system 
The conceptual mechanism by which attrihutes, 
notifications, operations, and 

behavior are acquired by a subclass from its superclass. 
An integer value that identifies a specific instance of a 
managed object and is unique within its managed object 
class. 

An object oriented programming language from Sun 
Microsystems that is interpreted, allowing applications to 
run on many platforms without change. 
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APPENDIX A-continued 



APPENDIX A-continued 



Logical 
Identifier 



Managed 
Object 



Managed 
Object Class 

Managed 

Object Class 

Code 

Managed 

Object 

Identifier 

Method or 

Operation 

MIB 



Network 
Element 

Network 
Element 
Detailed 
Status Applet 
Network 
Element Status 



Notification 



OAI AP 
ORB 

Object 
Identifier 
Persistent 
Attribute 

RAP API 



RCSAP 
Service Object 



Session 



SNTMP 



An integer value which represents the logical number of 
a device or interface (e.g., AP4). Note that there is no 
direct correlation between a logical id and 
instance id. 

An abstract representation of a resource that may be 

managed by the network management platform. 

Examples include a network element, a maintenance 

unit, network element summary, data link. 

A named set of managed objects that share the same sets 

of attributes, notifications and management operations. 

An example is the AP managed object class. 

A code that identifies a specific managed object class 

(unique to the system). This code is a constant 

(enumeration or integer definition). 

The combination of managed object class code and 

instance identifier defines the managed object identifier. 

Also abbreviated as an MOID. 

An operation or method on a managed object performs 

an action. 

Management Information Base: a data definition of 
Network Element objects to be managed by a 
Element Manager, written in an Internet-standard 
language, specific to the SNMP protocol. 
Message Mapping Application: the application which 
maps between the Autoplex Base Station Interface (ABI) 
call state and message sequence and 
the IS- 634 call state and message sequence. MMA 
is sometimes referred to as Open A Interface (OAI). 
A functional component of the Autoplex system such as 
a cell site, Application Processor (AP), Call Processing 
Data Node (CDN), Executive Cellular Processor (ECP). 
A JAVA applet depicting detailed status on the managed 
objects belonging to the network element. A sample 
view of the Network Element Detailed Status Applet 
can be found in Attachment 2 on the AP Web Page. 
Managed object attributes and their corresponding values 
that represent the status of the NE. The PlanR APCC NE 
status consists of status for the RCS-AP, and IS-634-AP 
managed objects, an active alarm list, and a table of 
outstanding commands. 

Information sent by an agent to a manager when an event 
occurs at the associated network clement This includes 
alarmed and informational messages, notification of 
configuration changes within the network element, as 
well as acknowledgments to technician input commands. 
An AP running the OAI application. 
Object Request Broker 

The combination of managed object class code and 

instance identifier which uniquely identifies any managed 

object instance in the system. Information 

stored and kept current irrespective of any client 

requests (eg., maintenance state). 

A general API for spawning a process and obtaining the 

results of the process execution. Generally, RAPs will 

be used to carry out a maintenance 

command on an AP resource. RAPs may spawn other 

processes, if necessary. 

Reliable Cluster Computing. A Highly- Available (HA) 
product from Lucent Technologies that provides the 
software and hardware components to enhance the 
reliability, availability and maintainability of a HA 
or clustered system. 

Radio Cluster Server. The application runs on the AP 

to provide call processing and OA&M functionality for 

the PlanR microcell. The software for 

this application is ported from the Radio Cluster 

Controller of a Scries II cell. 

The AP that hosts the RCS application. 

The object that provides services for a managed object 

class. Client applications acquire a reference to this 

object (in CORBA they bind to the object). An example 

is the AP service object and the Session service object. 

Each client must establish a unique session that is used to 

validate access permissions and for subsequent routing of 

notifications. 

Simple Network Management Protocol: an Internet- 
standard protocol for managing Network Elements from a 
Network Manager; provides three basic operations: 
GET, SET, and TRAP (autonomous notification). 



SNMP Agent 



SNMP Trap 

10 State Change 

Status 
Information 
System 
Summary 

15 APP 1 ^ 
TI/OP 

X Terminal 



The Software entity that resides on the Network Element 

and interfaces to the Network Manager via the SNMP 

protocol. This process listens on a specific 

UDP port in order to receive SNMP requests from 

the Manager and forwards TRAPs from the NE 

to the Manager. 

An autonomous notification from the Network Element 
to the Network Manager. 

A change in one or more of the attributes associated with 
a managed object. 

Current attribute values for a managed object instance. 

A JAVA applet that displays a summary of the status of 
all network elements in the system. In Attachment 2, 
an example of the System Summary Applet can be found 
on the Network Web Page. 

Technician Interface and Output Processor. The Autoplex 

subsystem where input commands and 

output reports are handled. 

A type of client terminal that only displays the X 

protocol and can not host the EMS client applications. 

Instead, the client applications run on the Server 

and are displayed (via the X protocol) on the X terminal. 
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1. GLOSSARY 



ACF Agent Configuration File 

AP Application Processor 

APCC Application Processor Cluster Complex 

API Application Programming Interface 

ASN.l Abstract Syntax Notation One 

30 OS Client/Server 

CDPD Cellular Digital Packet Data 

CD-ROM Compact Disk - Read Only Memory 

CHAP Command Handler Access Point 

CMIP Common Management Information Protocol 

COGS Cost of Goods 

35 CORBA Common Object Request Broker Architecture 

DAT Digital Audio Tape 

DCI Digital Computer Interface 

DELPHI Desktop Windows Visual Development 

Tool from Borland 
Emergency Action Interface 
Emergency Interface 
Event Configuration File 
Executive Control Processor 
Executive Control Processor Complex 
Ethernet Interface Node 

Element Management Application Programming 
Interface 

Element Management System 
File Transfer Protocol 
Graphical Client Interface 
High Availability 

High Availability Operations and Management Platform 
Hewlett Packard 
HP Open View 

HP Open View Network Node Manager 
HyperText Markup Language 
Hypertext Transfer Protocol 
Internet Control Message Protocol 
Interface I>efinition Language 
internal database subsystem 
Internet Protocol 

HPOVNNM component used to monitor up/down 
status of network elements 
JAR JAVA Archive 

LAN Local Area Network 

LMT Local Maintenance Terminal 

Mbytes Megabytes 
MIB Management Information Base 

MMA Message Mapping Application 

MO Managed Object 

MOID Managed Object Identifier 

NE Network Element 

65 NEST Network Element Status Table 

NLS Network Language Support 



EAI 

40 ECF 
ECP 
ECPC 
EIN 
EMAPI 

45 EMS 
FTP 
GUI 
HA 

HA-OMP 
HP 
50 HPOV 

HPOVNNM 

HTML 

HTTP 

ICMP 

IDL 

55 

IP 

ipmap 
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APPENDIX A-continued 


NMS 


Network Management System - obsolete 




term, replaced by EMS 


OAI 


Open A Interface 


OA&M 


Operations, Administration and Maintenance 


OMG 


Object Management Group 


OMP 


Operations and Management Platform 


ORB 


Object Request Broker 


ovspmd 


Open View System Process Management Daemon 


ovstart 


HPOVNNM startup script, used to start 




up HP OpenVicw runtime 


ovtrapd 


Open View Trap Daemon 


ovw 


Open View Windows 


ovwdb 


HPOVNNM map database manager 


pmd 


PostMaster Daemon (part of HPOVNNM) 


PVM 


Platform Virtual Machine 


RAP 


Resource Administration Process 


RCC 


Reliable Cluster Computing 


RCS 


Radio Control System 


ROP 


Read Only Printer 


SCANS 


Software Change Administration and Notification System 


SDP 


Status Display Pages 


SLIQ 


Qmodem's defined scripting language 


SNMP 


Simple Network Management Protocol 


SSL 


Secure Socket Layer 


SU 


Software Update 


TCP 


Transmission Control Protocol 


TI/OP 


Technician Interface and Output Processor 


UDP 


Client Datagram Protocol 


UX 


UNDC subsystem 


WAN 


Wide Area Network 


xmnevents 


X Network Management Events Browser 




(part of HPOVNNM) 
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What is claimed is: 

1. In a telecommunications network having a plurality of 
network elements, a method of managing at least one of the 
network elements, comprising the steps of: 

connecting a management computer to an element man- 
agement server through a communication link includ- 
ing a computer internet; 

coupling the at least one of the plurality of network 
elements to the element management server through the 
computer internet including coupling the at least one of 
the plurality of network elements to an associated 
applications processor with a management agent appli- 
cation for interfacing the element management server 
with the network element; and 

managing the at least one of the plurality of network 
elements via communications conveyed through the 
element management server between the management 
computer and the at least one network element, includ- 
ing the steps of 

receiving requests at the network element from a plu- 
rality of different management computers to poll for 
network element attributes which are the same, 

polling for the attributes which are the same only as if 
there were only one request for polling of the same 
attributes, and 

providing the results of the polling of the same 
attributes to all of the different management com- 
puters that requested polling of the same attributes. 

2. The method of claim 1 in which the step of managing 
includes the steps of 

generating from the management server an interactive 
web page with objects associated with management of 
the at least one network element, 

transmitting the interactive web page from the manage- 
ment server through the computer internet to the man- 
agement computer, and 

displaying the interactive web page at the management 
computer for management communications between 
the management computer and the at least one network 
element 
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3. The method of claim 2 in which the objects of the 
interactive web page include objects associated with at least 
one of operation, administration and maintenance of the at 
least one network element. 

4. The method of claim 3 in which the web page includes 
objects associated with all three of operation, administration 
and maintenance of the at least one network element. 

5. The method of claim 2 including the step of generating 
signals through interaction with the interactive web page at 
the management computer to achieve at least one of 
command, control and fault management of the network 
element. 

6. The method of claim 5 in which the step of generating 
includes the step of generating signals through interaction 
with the interactive web page at the management computer 
to achieve all three of command, control and fault manage- 
ment of the network element. 

7. The method of claim 2 in which the interactive web 
page includes a menu of individual maintenance unit com- 
mand options. 

8. The method of claim 2 in which the interactive web 
page includes a detailed status summary page for the at least 
one individual network element. 

9. The method of claim 2 in which the interactive web 
page includes a high level system status summary of all the 
plurality of network elements. 

10. The method of claim 2 in which the interactive web 
page includes a list of all active alarms within the telecom- 
munications network. 

11. The method of claim 1 in which 

the applications processor includes a maintenance appli- 
cation for performing maintenance of the network 
element, and the step of coupling includes the step of 

interfacing command request from the element manage- 
ment server through the management agent application 
to the maintenance application to selectively perform 
maintenance tasks. 

12. The method of claim 1 in which the step of interfacing 
by the network element includes the step of providing the 
element management server with applications processor 
specific events and command acknowledgements. 

13. The method of claim 1 in which the computer internet 
is the world wide web and the steps of connecting and 
coupling include the step of operating world wide web based 
JAVA applications at the management computer and the 
element management server. 

14. The method of claim 1 in which the management 
agent application responds to various actions and the step of 
managing includes the step of correlating responses from the 
management agent application with the actions which 
caused the actions. 

15. The method of claim 1 in which the step of managing 
includes the step of automatically routing command 
responses, polling results and traps back to the management 
computer. 

16. The method of claim 1 in which the step of connecting 
includes the step of enabling the connection in response to 
entry of a correct password at the management computer. 

17. The method of claim 16 including the step of encrypt- 
ing the password prior to sending to the management server. 

18. The method of claim 1 in which the step of managing 
includes the steps of 

selecting network element attributes from a plurality of 

network element attributes available for polling, and 
polling for only the selected network element attributes. 

19. The method of claim 1 including the step of auto- 
matically updating a list of active alarms of the network 
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element upon occurrence of either one of actuation of a new 
alarm and clearing of a former alarm. 

20. In a communication network having a plurality of 
network elements, a method for managing a network 
element, comprising the steps of: 

selectively running a management application at a plu- 
rality of different work stations for command, control 
and fault management of the network element; 

interfacing an element management server through a 
computer internet to the plurality of different work 
stations to provide distributed network element man- 
agement services to the management application at all 
of the plurality of work stations; 

interfacing the network element with the element man- 
agement server through a management agent applica- 
tion associated with the network element for commu- 
nicating command acknowledgment and command 
requests through the computer Internet between the 
element management server and the network element 
using a simple node management protocol, and includ- 
ing the steps of 

establishing a set of SNMP service objects that commu- 
nicate with the network element, establishing a SNMP 
mediator process that communicates with the SNMP 
service objects, 

polling for the SNMP service objects, and 

converting commands of a managed object to SNMP set 
commands; 

monitoring the operation of events within the communi- 
cation network; and 

diminishing the operation of events to prevent overload- 
ing of the communication system. 

21. The method of claim 20 in which the element man- 
agement server includes an object server having managed 
objects representing the network element and other 
resources of the system. 

22. The method of claim 20 including the step of filtering 
events of the network element. 

23. The method of claim 22 in which the events of the step 
of filtering events includes at least one of the events of alarm 
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notification, state change and configuration change to the 
element network system server. 

24. The method of claim 20 in which the step of inter- 
facing the network element includes the step of maintaining 

5 within the element management server a list of current 
active alarms within the network. 

25. The method of claim 20 in which 

the management application is written in JAVA, and 
the step of interfacing the work stations with the element 
to management server is performed through an interactive 

web page that visually displays a menu of command, 

control and fault management options. 

26. The method of claim 25 in which the web page 
includes a separate status summary display for each of the 

15 command, control and fault management options. 

27. The method of claim 25 in which the web page 
includes a display of a list of active alarms for all network 
elements within the communication network. 

28. In a telecommunications network having a plurality of 
20 network elements, a method of managing at least one of the 

network elements, comprising the steps of: 

connecting a management computer to an element man- 
agement server through a communication link includ- 
ing a computer internet; 
25 coupling the at least one of the plurality of network 
elements to the element management server through the 
computer internet in which the network element has a 
management agent application; 
managing the at least one of the plurality of network 
30 elements via communications conveyed through the 
element management server between the management 
computer and the at least one network element; 
queuing multiple commands simultaneously received 
from a plurality of different management computers 
35 including the one management computer; and 

successive responding to the multiple commands by send- 
ing responses to appropriate ones of the different man- 
agement computers that originated the commands, 
40 respectively. 

***** 
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